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.
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.
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.
No es event-driven vs request-response. Es event-driven + request-response.
Los sistemas maduros combinan ambos.
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
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.
Contacto
contacto@karvon.mx
56 1995 1546
Av Convento de Actopan #41 Col Las Margaritas Ampliacion
Tlalnepantla Edomex cp 54050
