# 12. Sincronía y asincronía Cómo elegir entre un request síncrono y un evento asíncrono, dónde caben las queues, el outbox, los retries y el backpressure. - **Author:** Fedor Chishchin - **Level:** advanced - **Reading time:** ~25 minutos de lectura - **Published:** 2026-05-23 - **Source:** https://fedorthinks.com/es/learn/software-architect-12-sync-async --- ## 1. La idea central 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. ## 2. Ejemplo y antiejemplo 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. #### Autoevaluación - ¿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? Siguiente módulo: [Rendimiento](./software-architect-13-performance).