Arquitectura Dirigida por Eventos: ¿Kafka o RabbitMQ para Escalar?

Lanzar un sistema distribuido y esperar que las peticiones HTTP síncronas mantengan la cordura es el equivalente técnico a jugar al teléfono roto con un megáfono: eventualmente, alguien se queda sordo o el mensaje se pierde. La arquitectura dirigida por eventos (EDA) no es una moda, es la respuesta a la fragilidad de los sistemas acoplados que mueren cuando un solo servicio tarda 200ms más de lo esperado.

El fin del acoplamiento temporal

En una arquitectura tradicional, si el Servicio A necesita que el Servicio B procese algo, espera una respuesta. Si B está caído, A falla. EDA rompe esta cadena. Los servicios no se llaman entre sí; emiten hechos (eventos) sobre lo que ha sucedido. Un evento es una notificación inmutable de que algo ocurrió en el pasado: OrderPlaced, PaymentValidated, InventoryDepleted.

La ventaja no es solo técnica, es de negocio. Permite que múltiples consumidores reaccionen al mismo evento sin que el productor sepa siquiera que existen. Esta topología de 'publicar y olvidar' es lo que permite que empresas como Uber o Netflix manejen millones de transacciones por segundo sin colapsar bajo el peso de las latencias de red.

Kafka vs. RabbitMQ: No son lo mismo y nunca lo fueron

Es común escuchar que ambos son "colas de mensajes", pero operan bajo filosofías radicalmente distintas. La elección incorrecta aquí puede costarle meses de refactorización.

RabbitMQ: El cartero inteligente

RabbitMQ es un broker de mensajes tradicional. Se asegura de que el mensaje llegue del punto A al punto B. Una vez que un consumidor confirma que leyó el mensaje (ACK), este desaparece de la cola. Es ideal para tareas transaccionales donde el orden exacto y la entrega garantizada son críticos, pero no necesitamos volver a leer el pasado.

Apache Kafka: El diario inmutable

Kafka es un log de eventos distribuido. No borra los mensajes al leerlos; los almacena en disco durante un tiempo determinado (retención). Esto permite que un nuevo servicio se conecte hoy y lea todo lo que pasó hace tres días para reconstruir su estado. Es, esencialmente, una base de datos optimizada para escritura secuencial masiva.

"Usa RabbitMQ si necesitas enrutamiento complejo y lógica de prioridad. Usa Kafka si necesitas procesar flujos de datos en tiempo real y persistencia a prueba de balas."

• RabbitMQ: Push-based. El broker empuja mensajes a los consumidores.
• Kafka: Pull-based. Los consumidores piden datos al broker a su propio ritmo.
• Escalabilidad: Kafka escala horizontalmente de forma nativa mediante particiones; RabbitMQ requiere configuraciones de clúster más delicadas para volúmenes masivos.

Patrones de implementación real

Implementar EDA no es solo instalar un broker. Requiere patrones específicos para evitar el caos de datos:

1. Outbox Pattern: Evita la desincronización entre tu base de datos y el broker. Escribes el evento en una tabla de 'Outbox' dentro de la misma transacción que tus datos de negocio, y un proceso separado lo publica.
2. Event Sourcing: En lugar de guardar solo el estado actual (ej: saldo = 100), guardas todos los eventos que llevaron a ese estado (+50, +70, -20).
3. CQRS (Command Query Responsibility Segregation): Separas la escritura (Comandos) de la lectura (Consultas), usando eventos para mantener la vista de lectura actualizada.

Ejemplo de código: Productor en Node.js con KafkaJS

const { Kafka } = require('kafkajs');

const kafka = new Kafka({
  clientId: 'order-service',
  brokers: ['localhost:9092']
});

const producer = kafka.producer();

const run = async () => {
  await producer.connect();
  await producer.send({
    topic: 'orders',
    messages: [
      { value: JSON.stringify({ id: '123', status: 'created', user: 'juls_user' }) },
    ],
  });
};

run().catch(console.error);

Estrategias de manejo de fallos: Dead Letter Queues (DLQ)

¿Qué pasa cuando un evento falla? No puedes simplemente detener el flujo. Aquí entran las DLQ. Si un consumidor no puede procesar un mensaje después de N intentos, el mensaje se mueve a una cola de "letras muertas" para inspección manual o reintento programado. Esto previene el envenenamiento de la cola, donde un solo mensaje malformado detiene todo el procesamiento de la empresa.

Cómo lo abordamos en Julsmind SAS

En Julsmind SAS, hemos diseñado arquitecturas de eventos para clientes en EE.UU. y LATAM que manejan picos de tráfico impredecibles. No aplicamos una solución única; analizamos si tu caso de uso requiere la baja latencia de RabbitMQ o el throughput masivo de Kafka en AWS MSK o Confluent. Nuestro enfoque desde Medellín es construir sistemas resilientes que no solo funcionen hoy, sino que permitan añadir nuevas funcionalidades mañana sin tocar una sola línea de código del núcleo transaccional.

Si tu arquitectura actual se siente como un castillo de naipes a punto de caer por una falla en la red, hablemos. Podemos ayudarte a migrar hacia un ecosistema dirigido por eventos que escale con tu negocio. Cuéntanos tu reto en nuestra página de contacto.