La comunicación síncrona bloquea al llamador hasta que llega una respuesta; la comunicación asíncrona envía un mensaje y continúa sin esperar. Cada una crea diferentes compensaciones en acoplamiento, latencia y resiliencia.
Comparación
| Aspecto | Síncrona (REST/gRPC) | Asíncrona (messaging) |
|---|---|---|
| ¿El llamador espera? | Sí | No |
| Acoplamiento temporal | Ajustado | Flexible |
| Resiliencia a interrupciones | Baja | Alta (broker almacena) |
| Coherencia | Inmediata | Eventual |
| Complejidad | Menor | Mayor |
| Depurabilidad | Más fácil (lineal) | Más difícil (flujos) |
Visualización
text
SYNC: Caller ──request──▶ Service
Caller ◀─response── Service (blocked the whole time)
ASYNC: Caller ──message──▶ [ Queue ] ──▶ Service
Caller continues immediately; Service handles it later
Regla práctica
- Usa sync cuando el usuario necesita una respuesta ahora (ej. cargar un perfil).
- Usa async para trabajo en segundo plano, fan-out y para sobrevivir a interrupciones de sistemas posteriores (ej. enviar un email de confirmación).
Trampa
Async oculta fallos — un mensaje perdido o tóxico puede romper silenciosamente un flujo de trabajo. Necesitas dead-letter queues y monitoreo.
Por qué es importante
La elección controla directamente cómo se propagan los fallos: las llamadas síncronas fallan rápido y visiblemente, los mensajes asíncronos desacoplan pero posponen los problemas a los consumidores.
Mezclar bien ambas — sync en el borde, async para flujos de trabajo — es una habilidad central en la construcción de microservicios resilientes.
