Por qué a veces conviene no esperar la respuesta: asincronismo, picos de carga y componentes que se comunican sin conocerse.
→ avanzar · S notas del orador · F pantalla completa · O vista general
Deslizá hacia abajo para recorrerla. Las simulaciones se activan al llegar a cada una.
La app pide una factura en PDF y se queda esperando hasta que el servicio termina. Mientras tanto, ese lugar está ocupado.
Mismo trabajo, misma carga. Con una cola, la app deja el mensaje y sigue: un worker lo procesa cuando puede.
El usuario espera todo el trabajo, y si no hay lugar recibe un 503.
La respuesta es inmediata: 202 Aceptado. El trabajo lo hace un worker después… si hay alguno.
Los workers trabajan a su ritmo, llegue como llegue la carga. Lo que sobra espera en la cola.
Sin cola, todo lo que no entra en el momento se rechaza.
Con cola, el pico se guarda y se procesa después.
Llegan 4 mensajes por segundo y un worker procesa 1. Sumá workers hasta que la cola deje de crecer.
La app y los workers no se conocen y no necesitan estar levantados al mismo tiempo. Lo único que comparten es la cola.
Romperlo en vivo: un worker se cae justo antes de confirmar (ack), o llega un mensaje que siempre falla.
El que produce y el que consume no se conocen ni tienen que estar levantados a la vez.
Los workers trabajan a su ritmo; lo que sobra espera en la cola en vez de rechazarse.
Más workers sin tocar al productor. Si uno se cae, el mensaje vuelve a la cola.
El resultado llega después. No sirve cuando el usuario lo necesita para seguir.
Una cola para operar y monitorear; seguir qué pasó con un mensaje cuesta más.
Hay que procesar de forma idempotente, tener DLQ y vigilar que la cola no crezca sin control.
En la práctica: RabbitMQ · Amazon SQS · Azure Service Bus / Storage Queues · Redis