A medida que las aplicaciones crecen, los patrones síncronos de solicitud-respuesta se convierten en un cuello de botella. La arquitectura orientada a eventos (EDA) ofrece una alternativa poderosa: los componentes se comunican mediante eventos, permitiéndoles escalar y fallar de forma independiente sin afectar todo el sistema. En este artículo profundizamos en los conceptos clave de EDA, desde message brokers hasta event sourcing y CQRS.
Message Brokers: El corazón de EDA
Un message broker actúa como intermediario entre productores (servicios que publican eventos) y consumidores (servicios que procesan eventos). Apache Kafka, RabbitMQ y Amazon SQS son las opciones más utilizadas, cada una con sus propias fortalezas. Kafka destaca en streaming de eventos de alto rendimiento con almacenamiento duradero, mientras que RabbitMQ es más flexible con patrones de enrutamiento como topic exchanges y dead letter queues.
Elegir el broker correcto depende de tu caso de uso: ¿necesitas entrega garantizada? ¿Capacidades de replay de eventos? ¿Qué tan importante es el orden? Kafka ofrece ordenamiento a nivel de partición y compactación de logs, mientras que RabbitMQ proporciona garantías de entrega más fuertes con acknowledgments y controles de prefetch.
// Productor de eventos con Kafka (Node.js)
const { Kafka } = require('kafkajs');
const kafka = new Kafka({
clientId: 'order-service',
brokers: ['kafka-1:9092', 'kafka-2:9092']
});
const producer = kafka.producer();
await producer.connect();
// Publicar un evento OrderCreated
await producer.send({
topic: 'order-events',
messages: [{
key: orderId,
value: JSON.stringify({
type: 'OrderCreated',
payload: { orderId, items, total },
timestamp: Date.now(),
correlationId: uuid()
})
}]
});Event Sourcing y CQRS
Event Sourcing almacena cada cambio de estado como un evento inmutable en un event store de solo escritura. En lugar de mantener solo el estado actual, tienes un registro de auditoría completo de todos los cambios. Esto permite reconstruir el estado en cualquier momento, lo cual es invaluable para debugging, compliance y analytics.
CQRS (Command Query Responsibility Segregation) separa las operaciones de lectura y escritura en modelos separados. El modelo de comandos procesa las acciones de escritura y publica eventos, mientras que el modelo de consultas mantiene vistas de lectura optimizadas. Esta separación permite escalar y optimizar cada modelo de forma independiente para su tarea específica.
- Usa consumers idempotentes para manejar eventos duplicados de forma segura
- Implementa dead letter queues para eventos que no pueden procesarse
- Agrega correlationId y causationId a cada evento para trazabilidad
- Considera schema registry (Avro/Protobuf) para gestión de contratos de eventos
- Empieza simple: no todos los sistemas necesitan event sourcing
- Monitorea el consumer lag para detectar cuellos de botella temprano
Patrones de manejo de errores y resiliencia
En sistemas distribuidos orientados a eventos, las fallas son inevitables. El patrón Saga coordina transacciones entre múltiples servicios definiendo acciones compensatorias para cada paso. Si el servicio de pago falla después de crear una orden, la saga automáticamente envía un evento compensatorio para cancelar la orden.
Implementa circuit breakers alrededor de llamadas a servicios externos y usa backoff exponencial con jitter para reintentos. Combina esto con dead letter queues y alertas para que ningún evento se pierda permanentemente. También considera el patrón Outbox para publicación confiable de eventos: escribe eventos en una tabla outbox en la misma transacción de base de datos que tu cambio de dominio, y deja que un proceso separado los publique al message broker.
Consejo Pro
Comienza con un setup pub/sub simple usando RabbitMQ o Amazon SQS para tu primer flujo orientado a eventos. Identifica una llamada API síncrona en tu sistema que sea un cuello de botella y reemplázala con un evento asíncrono. Mide el impacto en latencia y rendimiento. Descubrirás que incluso este pequeño paso ya produce mejoras significativas en escalabilidad y resiliencia del sistema.
Compartir este artículo