Avisar que algo pasó y que cada interesado haga lo suyo: consumidores distintos, desacoplados y a su propio ritmo.
→ avanzar · S notas del orador · F pantalla completa · O vista general
Deslizá hacia abajo para recorrerla. Las simulaciones se activan al llegar a cada una.
El cliente pide una orden. Órdenes llama en serie a Facturación, Stock, Mails y Analytics, y recién cuando todos responden le contesta al cliente.
Órdenes publica OrdenCreada en el broker y le contesta al cliente apenas el broker la acepta. El broker deja una copia en la cola de cada suscriptor.
Analytics tarda 1,2 s por evento y llegan 1,5 por segundo: se atrasa. Los demás ni se enteran.
La orden ya existe, pero Stock todavía no procesó el evento. Durante esa ventana, los datos no coinciden.
Facturación escucha OrdenCreada y, cuando termina, publica FacturaEmitida. Mails escucha ese segundo evento para mandar la factura.
El flujo está repartido entre suscriptores. Hace falta un id de correlación y trazas para reconstruir la historia de una orden.
Cambiar un campo de OrdenCreada puede romper a suscriptores que ni conocés. Versionar con cuidado.
Lo mismo que en las colas: cada suscriptor tiene que ser idempotente y no asumir el orden.
Reintentos y DLQ por suscriptor, para que un evento roto no frene a ese consumidor para siempre.
Por un rato, no todos están al día. El diseño y la interfaz tienen que tolerarlo.
El broker hay que operarlo, monitorearlo y hacerlo resistente a fallas: si se cae, nadie se entera de nada.
En la práctica: Kafka · RabbitMQ (exchanges fanout/topic) · Amazon SNS + SQS / EventBridge · Google Pub/Sub · Azure Service Bus topics / Event Grid