Arquitectura event-driven: workflows en tiempo real sin complejidad innecesaria

Eventos cuando el negocio es asíncrono

Si tu dominio reacciona a “algo ocurrió” (pedido creado, pago confirmado, documento validado), un modelo event-driven desacopla productores y consumidores mejor que cadenas síncronas frágiles.

Elige el patrón correcto

Necesidad Enfoque Fan-out a varios consumidores Event bus / topics Trabajo fiable con reintentos Cola + workers Proceso largo con estado Orquestación (sagas / workflows) Consultas eventualmente consistentes Proyecciones / CQRS ligero

Streaming vs batch

No elijas Kafka “porque escala”. Elige según latencia de negocio y volumen. Muchos procesos diarios se resuelven con colas clásicas y jobs batch bien instrumentados.

Contratos de evento

Nombre estable (order.paid.v1).
Schema versionado.
Idempotencia en consumidores.
Orden solo donde el dominio lo exige (y documenta el coste).

Observabilidad desde el día uno

Correlación entre comando → evento → proyección. Dead-letter queues con runbooks. Alertas por lag, no solo por CPU.

La complejidad útil es la que compra desacoplamiento; el resto es moda.

Conclusión

Empieza con un flujo extremo a extremo, mide, y solo entonces añade buses globales. Para diseñar el mapa de eventos de tu producto, hablemos.