Los workers consumen de una cola y ejecutan jobs. Use una instancia pequeña dedicada o ejecute junto con la app. Escale workers horizontalmente; asegure idempotencia y manejo dead-letter. Monitore profundidad de cola y tiempo de procesamiento.
Qué hacen los workers
- Consumen: Sacan mensajes de una cola (Redis list/stream, RabbitMQ, SQS, etc.). Cada mensaje dispara un job (ej. enviar email, procesar imagen, sincronizar datos).
- Desacoplan: La app encola y devuelve; los workers procesan en async. Maneja picos y tareas largas sin bloquear la capa web.
- Backends: Redis (colas o streams simples), RabbitMQ (enrutado, DLQ), SQS (gestionado, a escala). Elija por latencia, durabilidad y preferencia de ops.
Opciones de despliegue
- Instancia(s) dedicada(s): VPS pequeño o contenedor(es) que solo ejecutan workers. Aísla CPU/memoria de la app; más fácil escalar workers de forma independiente.
- Junto con la app: Workers en el mismo servidor que la app. Más simple para setups pequeños. Riesgo: jobs pesados pueden competir con la app. Use process manager y límites de recurso.
- Serverless: Lambda, Cloud Run o similar para jobs orientados a eventos. Paga por invocación; sin coste en idle.
Fiabilidad
- Idempotencia: Diseñe jobs para que ejecutar dos veces (ej. retry tras timeout) no cause efectos secundarios duplicados. Use claves de idempotencia o claves naturales.
- Dead-letter: Cuando un job falle tras N intentos, muévalo a una cola dead-letter (DLQ). Monitore la DLQ; corrija mensajes malos o replay tras corregir el bug.
- Visibilidad: Monitore profundidad de cola (backlog), tiempo de procesamiento y tasa de error. Alerte por backlog creciente o pico de fallos.
Resumen
Los workers consumen de una cola y ejecutan jobs. Use instancia dedicada o ejecute junto con la app. Escale horizontalmente; asegure idempotencia y dead-letter. Monitore profundidad de cola y tiempo de procesamiento.
