¿Qué es una cola de trabajos y por qué tu aplicación necesita una?
Publicado el 2026-10-20 por frfrand
Qué es una cola de tareas, cómo trabajan los workers, reintentos, idempotencia y qué hacer con trabajos fallidos.
Una cola de trabajos permite guardar tareas pendientes para que uno o varios procesos las ejecuten sin obligar al usuario a esperar mientras se hacen. Por eso aparece detrás de correos, informes, videos, importaciones y automatizaciones.
Imaginá que alguien pulsa «Generar reporte mensual» y la aplicación tarda tres minutos en terminar. Mantener el navegador esperando todo ese tiempo sería incómodo y frágil. Una cola ofrece una forma mejor de organizar ese trabajo.
La comparación con una cocina
En un restaurante, los pedidos llegan, se anotan y después los cocineros los preparan. El camarero no se queda junto al horno esperando cada plato: puede seguir atendiendo a otras mesas.
En una aplicación, un servidor web puede registrar un trabajo en una cola y responder inmediatamente: «Recibimos tu solicitud». Después un worker toma la tarea, la procesa y registra si terminó, falló o necesita un nuevo intento.
La cola separa el momento de pedir algo del momento en que efectivamente se completa.
¿Cómo se organiza un sistema con colas?
Habitualmente hay tres partes:
Productor: la aplicación que crea la tarea. Por ejemplo, una API que recibe la solicitud de generar un PDF.
Cola o broker: el mecanismo que mantiene los trabajos disponibles para sus consumidores, según sus reglas de entrega y persistencia.
Consumidor o worker: el proceso que toma trabajos y ejecuta las operaciones.
Un resultado también puede guardarse en una base de datos para que el usuario consulte el progreso. No todas las colas incluyen almacenamiento de resultados ni interfaces de seguimiento.
Ejemplo real: enviar mil correos
Supongamos que una tienda debe avisar a mil clientes sobre una modificación de horarios. No tendría sentido que quien pulsó «Enviar» se quedara con la página bloqueada hasta el último correo.
La aplicación puede crear trabajos de envío y procesarlos con workers. Así también es posible limitar cuántos mensajes salen simultáneamente y cómo reaccionar cuando el proveedor de correo devuelve un error temporal.
Pero existe un detalle: el hecho de que una tarea esté en cola no garantiza que el correo llegue al destinatario. Hay que distinguir trabajo aceptado, envío intentado y entrega confirmada.
¿Qué pasa cuando un worker falla?
Una tarea puede fallar porque se cayó una conexión, un archivo no existe o un servicio externo está fuera de línea.
Algunos sistemas permiten reintentar el trabajo, esperar un intervalo o enviarlo a una cola de fallos. No conviene reintentar infinitamente sin control: podrías repetir una operación que siempre falla y consumir todos los recursos.
Además, un worker puede completar una acción pero fallar antes de registrar que terminó. Si el sistema vuelve a ejecutar esa tarea, podrías repetir un cobro o enviar dos veces una notificación.
La importancia de la idempotencia
Una operación idempotente está diseñada para que repetirla no provoque efectos adicionales no deseados respecto de su resultado final. Para tareas como «confirmar este pago» o «registrar esta reserva», es fundamental evitar duplicaciones.
Podés usar identificadores únicos y registros de operaciones procesadas. También conviene diseñar la base de datos para impedir estados inconsistentes, en lugar de depender únicamente del comportamiento de la cola.
Que un sistema prometa entrega «al menos una vez» implica precisamente que pueden existir ejecuciones repetidas. Esa garantía no es lo mismo que ejecución exactamente una vez de todo el negocio.
¿Redis sirve como cola?
Redis puede formar parte de arquitecturas de mensajería y colas; herramientas como Celery y otros sistemas pueden utilizar brokers adecuados según su configuración.
Pero una caché y una cola no son lo mismo, aunque a veces utilicen el mismo software. Una entrada de caché puede perderse sin más consecuencias que repetir una consulta; una tarea de facturación perdida puede resultar mucho más grave.
Cuando las tareas son importantes, revisá durabilidad, confirmaciones, reintentos, supervisión y recuperación.
¿Cuándo no necesitás una cola?
Si una operación tarda unas milésimas, termina dentro de la solicitud y no tiene requisitos especiales, incorporar varios workers y un broker puede ser complejidad innecesaria.
Antes de agregar otra pieza de infraestructura, medí cuánto tarda el trabajo, qué sucede cuando falla y cuántas tareas llegan al mismo tiempo.
¿Qué tiene que ver con ArduMaker?
En ArduMaker se pueden ejecutar aplicaciones y servicios como Redis y n8n dentro de VPS. Un backend desplegado allí puede organizar trabajos con una cola y workers si su diseño lo requiere. Pero la plataforma no define automáticamente la política de reintentos ni evita duplicaciones: esa lógica pertenece al proyecto.
En una frase: una cola permite diferir y distribuir trabajos. Lo difícil no es poner tareas en espera, sino saber qué hacer cuando se repiten, fallan o desaparecen.
Fuentes: Guía de Celery · Documentación de Redis Streams · Qué es un worker en ArduMaker.