Arquitecturas orientadas a eventos
Los eventos desacoplan a quien escribe de quien lee. También ocultan el grafo de llamadas. Úsalos cuando el dominio ya es una secuencia de hechos, no para evitar una API.
Experiencia personal
En ProCrédito v2 y trabajo relacionado de ERP, los servicios Laravel emiten hechos a Redis Streams; workers en Python los consumen para procesamiento masivo. El productor no espera a cada consumidor. La escritura de dominio sigue perteneciendo a Laravel.
Perspectiva técnica
El diseño orientado a eventos es un intercambio: compras desacoplamiento temporal y pierdes un único stack trace. Es un buen intercambio cuando el productor no debería conocer a sus consumidores — facturación después de una orden, búsqueda después de un cambio de catálogo, notificaciones después de un pago.
Es un mal intercambio cuando el siguiente paso debe suceder o la acción de cara al usuario es una mentira. “Crear orden” que responde 201 antes de reservar inventario no es consistencia eventual. Es una API incorrecta.
Nombra los eventos como hechos que ya ocurrieron, en pasado, con un payload del que el productor puede responder. Si los consumidores necesitan consultar al productor para entender el evento, el evento es un ping, no un contrato.
Architecture
Hechos de entrada, reacciones de salida
Producer
Event log / broker
Consumer A
Consumer B
Consumer C
Perspectiva técnica. Los productores emiten hechos; los consumidores reaccionan sin una transacción compartida.