Event-Driven Architecture vs Request-Response: cuándo usar cada uno

En el diseño de sistemas modernos, pocas decisiones arquitectónicas impactan tanto como el modelo de comunicación entre servicios. Dos patrones dominan la conversación técnica: request-response y event-driven architecture (EDA).

Ambos funcionan, ambos escalan y ambos pueden fallar si se aplican fuera de contexto. La diferencia no está en la tecnología, sino en qué problema estás resolviendo.

Request-Response: cuando necesitas control, certeza y feedback inmediato

El modelo request-response es sincrónico: un servicio hace un call, espera una respuesta y continúa el flujo.

HTTP/REST, GraphQL y gRPC son sus implementaciones más comunes. En pocas palabras, un usuario hace login, el frontend hace un request al auth service, se validan credenciales y devuelve un JWT o un error.

Este modelo funciona muy bien en CRUD operations, APIs públicas, flujos simples y determinísticos, generalmente en casos donde la latencia debe ser mínima y predecible.

Dónde podría romperse, cuando un request dispara múltiples side effects, empiezas a encadenar servicios o el sistema escala en complejidad, no en usuarios. Aquí es dónde los modelos request-response pueden tener un acoplamiento muy estrecho.

Event-Driven Architecture: cuando el sistema reacciona

Un usuario hace una compra, entonces se emite un evento (Order Placed). A partir de ahí: inventory service reserva stock, el billing service genera factura, notification service envía correo y analytics service registra métricas.

Ninguno necesita hablar entre sí. Todos reaccionan al mismo event. Si uno falla, el resto sigue funcionando.

Ahora, event-driven systems podrían tener problemas con: el event ordering, la duplicación de eventos, idempotency, el debugging distribuido y con una observability más compleja. En estos casos, un mal diseño puede volverse opaco muy rápido.

El error común: pensar que es una guerra de modelos

No es event-driven vs request-response. Es event-driven + request-response.

Los sistemas maduros combinan ambos.

Request-response para comandos y consultas críticas
Events para propagación de estado, side effects y procesos desacoplados

Un checkout puede validar pagos vía request-response, pero notificar inventario, facturación y analítica vía eventos. La arquitectura siempre debe responder al dominio.

Siempre solemos decir, antes de elegir un modelo las preguntas clave no son técnicas

¿Necesitas consistencia inmediata o eventual?
¿El flujo es orquestado o coreografiado?
¿Qué pasa si un servicio no responde?
¿Cuánto acoplamiento puedes tolerar hoy… y mañana?

Conclusión

La diferencia entre un sistema robusto y uno frágil no está en usar Kafka o REST, sino en entender cuándo y por qué.

En nuestra experiencia, los proyectos que escalan mejor no son los que adoptan patrones complejos desde el día uno, sino los que “toman decisiones arquitectónicas alineadas al negocio y a su evolución real”.

Si tu sistema está creciendo, cambiando o mostrando fricciones que no son solo técnicas, probablemente la conversación ya no sea sobre herramientas, sino sobre arquitectura.