Software Architect · Módulo 12
Lo síncrono te da un modelo mental simple. Lo asíncrono te da resiliencia y desacoplamiento — pero exige nuevas garantías.
Queue · event · outbox · backpressure · retry
Elegir sync o async es elegir entre una respuesta inmediata y un procesamiento durable en el tiempo.
Una llamada síncrona encaja con una pregunta
Si el cajero pregunta el precio de un producto, la respuesta se necesita ahora. Si la tienda manda un reporte a contabilidad, eso puede ir en una queue.
Un request síncrono va bien cuando el usuario necesita el resultado ya: verificar el password, mostrar el precio, confirmar acceso. Es más simple para la UX y para debug, pero acopla la availability del caller y del callee.
Async encaja con trabajo que se puede hacer después: email, indexing, analytics, webhook delivery, generación de reportes, enrichment. Baja el coupling, pero exige estados, retries, una dead-letter queue y observability.
Un evento es un hecho, no una orden
"La puerta está abierta" es un hecho. "Abre la puerta" es una orden. Puedes mezclarlas, pero el sistema empezará a discutir sobre la intención.
Un event describe algo que ya pasó: OrderPlaced, PaymentCaptured, UserRegistered. Un command pide que algo pase: CapturePayment, SendEmail. En arquitectura conviene no mezclar estas formas.
Si un evento se usa como una orden oculta, el consumer queda dependiente de la intención interna del producer. Eso rompe el loose coupling.
La asincronía no debería ser el lugar donde los errores desaparecen sin ruido.
Ejemplo: transactional outbox
El oficinista anota la carta en el libro primero y la envía después. Si el correo se cae, el registro no se pierde.
Al crear un pedido, el servicio escribe el order y el outbox event en una misma transaction. Un worker aparte lee el outbox y publica el evento en el broker. Si el broker está temporalmente caído, el evento se queda en la base y se envía después.
El outbox cierra un hueco clásico: los datos se guardaron, pero el evento se perdió entre el commit y el publish.
Antiejemplo: la queue como bote de basura
Una bandeja de entrada no es un proceso. Si nadie la trabaja, el trabajo solo está escondido.
El equipo manda todas las operaciones pesadas a una queue, pero no define retry policy, idempotency, ordering, visibility timeout, DLQ ni alertas. En producción, los mensajes se cuelgan, se duplican o tardan horas en procesarse.
Una queue no hace que el sistema sea confiable por sí sola. Mueve la complejidad del request path al background processing.
- ¿El usuario necesita el resultado ahora mismo? - ¿Qué pasa si un mensaje se entrega dos veces? - ¿Dónde se guarda el hecho de que este evento tiene que publicarse? - ¿Cómo muestra el sistema el backlog y los failed jobs?