En los últimos tres años el término "event-driven" pasó de ser un patrón específico a convertirse en una recomendación genérica. Casi toda nueva arquitectura se justifica con eventos: "es desacoplada", "escala mejor", "es moderna". La realidad es más matizada.
Qué resuelve event-driven de verdad
El patrón event-driven brilla en tres contextos:
- Procesos con picos impredecibles donde una cola absorbe el golpe.
- Integraciones entre dominios donde acoplar por llamada síncrona crea dependencias frágiles.
- Sistemas donde la trazabilidad de "qué pasó" es central para auditoría o debugging.
Donde brilla menos es en sistemas simples con pocos usuarios, baja concurrencia y reglas de negocio claras. Ahí agregar un broker, un esquema de eventos, idempotencia y reproceso suele ser costo sin retorno.
Tres síntomas de que estás sobre-ingeniería
1. El equipo no puede dibujar el flujo de un caso de uso punta a punta sin abrir un diagrama de 30 cajas.
2. Hay eventos cuyo único consumidor es el mismo servicio que los emite.
3. La latencia de un proceso de negocio crítico depende de cuánto tarda un broker en aceptar un mensaje.
Cualquiera de estos tres es señal de que el modelo se alejó del problema.
Cuándo sí conviene
- Procesamiento de pagos, conciliaciones o cualquier flujo donde se requiere idempotencia fuerte.
- Pipelines de datos que alimentan múltiples consumidores.
- Integración entre sistemas legacy que no toleran llamadas sincrónicas largas.
Cuándo no
- CRUD clásico sobre una base de datos relacional.
- Aplicaciones internas con menos de 50 usuarios concurrentes.
- Productos nuevos donde todavía no se entiende bien el dominio.
Cierre
Antes de elegir event-driven, hay que entender qué problema se está resolviendo. Si la respuesta es "lo moderno" o "escala mejor", probablemente todavía no toca.
En CodeHub ayudamos a empresas a decidir si su próxima arquitectura necesita eventos o basta con una buena API REST bien diseñada.