¿por qué se usa Event-Driven Architecture?
imaginá que tenés un sistema con dos microservicios:
pagos
emails
cuando un pago se confirma, pagos llama a emails para enviar el comprobante.
pero la aplicación crece. ahora también hay que generar una factura, actualizar métricas y enviar una notificación.
para hacerlo, pagos empieza a llamar a cada uno de ellos.
cada funcionalidad nueva agrega una llamada más. con el tiempo, ese flujo se vuelve cada vez más difícil de mantener.
event-driven architecture propone otra forma de comunicarse.
cuando se confirma un pago:
pagos publica el evento "pago confirmado".
emails envía el comprobante.
facturación genera la factura.
métricas actualiza los dashboards.
si mañana agregás otro microservicio, solo tiene que reaccionar a ese evento. pagos no cambia.
por eso encaja tan bien con microservicios: cada uno mantiene una única responsabilidad y puede evolucionar sin depender directamente del resto.
obvio que no todo son ventajas. el sistema también se vuelve más complejo. aparecen desafíos como reintentos, eventos duplicados, orden de procesamiento y observabilidad.
en la práctica, suele haber un broker (como Kafka o RabbitMQ) que recibe el evento y lo distribuye a los microservicios suscriptos.