¿Qué es un worker y por qué las aplicaciones usan tareas en segundo plano?
Publicado el 2026-10-20 por frfrand
Workers explicados con ejemplos: colas, Celery, correos, PDFs, trabajos demorados, reintentos e idempotencia sin bloquear una web.
Un worker es un proceso que se encarga de ejecutar tareas fuera del recorrido principal de una aplicación. En desarrollo web suele utilizarse para trabajos que tardan demasiado como para mantener a una persona esperando frente a una página: generar archivos, procesar imágenes, enviar notificaciones o importar miles de registros.
No significa que el trabajo desaparezca. Simplemente se ejecuta en otro proceso, y muchas veces en otra máquina.
El ejemplo del restaurante
Imaginá un restaurante donde quien toma el pedido también debe preparar cada plato antes de atender al siguiente cliente. Sería un desastre: todos terminarían haciendo cola, aunque solo quisieran preguntar por la carta.
En una aplicación ocurre algo parecido cuando una solicitud HTTP debe esperar a que termine una operación pesada. Lo habitual es recibir la solicitud, registrar qué hay que hacer y delegar la tarea.
Entonces entra en escena el worker.
¿Qué diferencia hay entre la web, una cola y un worker?
La aplicación web atiende peticiones. La cola mantiene información sobre los trabajos pendientes. El worker obtiene trabajos y ejecuta la lógica correspondiente.
Por ejemplo, un cliente pulsa «generar informe». La web puede crear una tarea y devolver un identificador en pocos segundos. El worker la procesa y, al terminar, el usuario recibe un aviso o puede descargar el archivo.
Según la tecnología elegida, la cola y la ejecución pueden coordinarse con Redis, RabbitMQ u otros sistemas. Cada combinación ofrece distintas garantías.
Un caso práctico: envío de correos
Si se registra un usuario nuevo, la aplicación puede confirmar el registro y enviar un correo de bienvenida como tarea secundaria.
Pero cuidado: si el correo no llega, ¿qué debe pasar? ¿Se reintenta? ¿Cuántas veces? ¿Y si el proveedor de correo recibió el mensaje, pero el worker perdió la confirmación?
Esas preguntas importan porque una tarea ejecutada dos veces puede causar efectos duplicados. Enviar dos correos puede ser molesto; cobrar dos veces una compra sería mucho peor.
¿Qué significa idempotencia?
Una operación es idempotente cuando repetirla produce el mismo efecto relevante que ejecutarla una vez. Por ejemplo, establecer el estado de un pedido en «procesado» puede diseñarse para tolerar repeticiones.
Por el contrario, «sumar 10 € al saldo» no es idempotente si cada ejecución suma otros 10 €. Cuando las colas pueden repetir tareas, este detalle deja de ser teoría.
Una práctica común es utilizar identificadores únicos para no volver a aplicar el mismo efecto si ya se realizó.
¿Qué pasa si el worker se apaga?
Depende de cómo se gestionen los mensajes y las confirmaciones. Algunas configuraciones reconocen una tarea antes de ejecutarla; otras pueden devolverla a la cola después de una interrupción.
No existe una garantía universal de «se ejecuta exactamente una vez» por instalar Celery o Redis. Hay que comprender los reintentos, las confirmaciones, los tiempos máximos y cómo registrar resultados.
¿Qué es Celery?
Celery es una herramienta conocida del ecosistema Python para definir y ejecutar tareas distribuidas mediante workers y un sistema de mensajería. Se utiliza frecuentemente con Django, aunque no está limitado a ese framework.
Podés definir una tarea que procese un informe y enviarla a la cola desde el backend. Los workers ejecutan esa función cuando disponen de capacidad.
Para operar correctamente se necesita supervisión, registro de errores y configuración adecuada de la concurrencia.
¿Más workers significa más velocidad?
No siempre. Si todas las tareas compiten por la misma base de datos o consumen toda la memoria disponible, agregar workers puede empeorar la situación.
Hay trabajos limitados por CPU, otros por red y otros por servicios externos. Antes de aumentar procesos conviene medir cuánto tarda cada tarea y dónde está el cuello de botella.
También es importante limitar los reintentos: si un proveedor externo falla, no tiene sentido lanzar miles de intentos por segundo y agravar el problema.
¿Cuándo no necesitás un worker?
Si una operación termina en milisegundos y forma parte de la respuesta inmediata, introducir una cola puede agregar complejidad innecesaria.
El objetivo no es crear una arquitectura más grande, sino mantener la aplicación disponible cuando aparecen tareas prolongadas o poco predecibles.
¿Y en ArduMaker?
En ArduMaker se pueden gestionar aplicaciones y servicios que utilizan Redis y workers dentro de VPS. En sistemas con n8n y otros procesos en segundo plano, también importa separar el componente que recibe peticiones del que realiza trabajos demorados.
En resumen: un worker ejecuta tareas que no deberían bloquear la respuesta principal. Una cola ayuda a coordinarlas, pero la fiabilidad depende de cómo diseñes reintentos, errores y operaciones duplicadas.
Fuentes: Guía de tareas de Celery · Introducción a workers de Celery.