La arquitectura dirigida por eventos (EDA) es un estilo en el que los componentes del sistema se comunican publicando eventos —hechos del pasado expresados en pretérito ("PedidoCreado", "PagoConfirmado", "InventarioActualizado")— y reaccionando a los eventos que les interesan, en lugar de invocarse directamente unos a otros con llamadas síncronas. Esto desacopla emisores y consumidores: el emisor no sabe quién va a procesar el evento, y se pueden añadir nuevos consumidores sin tocar el emisor.
El sistema se construye sobre un broker de mensajería: Kafka (eventos persistentes con replay, ideal para sistemas grandes), RabbitMQ (mensajería tradicional con colas y exchanges), AWS SNS/SQS/EventBridge, Google Pub/Sub, NATS, Redis Streams. Los eventos se serializan en JSON, Avro o Protobuf, con un schema registry que versiona los contratos. Los consumidores procesan a su ritmo, idempotentemente y con reintentos automáticos ante fallos.
EDA encaja bien cuando hay flujos asíncronos de larga duración (proceso de pedidos, conciliaciones, integraciones con terceros), cuando hay que reaccionar al mismo hecho desde varios sitios (un pago confirmado dispara facturación, notificación, contabilidad, fidelización) y cuando la disponibilidad por encima del consenso instantáneo importa. No encaja para flujos simples request/response ni para invariantes que requieren consistencia transaccional inmediata.
En 10Code aplicamos EDA cuando el dominio lo pide: e-commerce con flujos de fulfillment, plataformas de pagos, integraciones con sistemas heredados, eventos analíticos. Empezamos siempre con un único broker bien operado, eventos versionados desde el día 1, observabilidad de cada cola y, sobre todo, idempotencia en los consumidores. Sin esa disciplina, EDA se convierte en una caja negra de difícil depuración.
En 10Code llevamos más de una década aplicando estas tecnologías a productos reales. Si quieres comentarnos tu caso, escríbenos y te respondemos personalmente.
Hablar con un ingeniero