¿Cómo ejecutas tareas en segundo plano con Celery?

Question

Accepted Answer

**Celery** es la herramienta estándar para ejecutar **tareas en segundo plano y programadas** en Django — trabajo que no debería bloquear la solicitud HTTP (enviar correos, procesar archivos, llamar a APIs lentas) o que se ejecuta en una programación. Las tareas se ponen en cola y se procesan de forma asincrónica mediante procesos **worker** separados.

## El problema que Celery resuelve

```python
# ❌ doing slow work inline blocks the response — the user waits, risks timeouts
def register(request):
    user = create_user(request.POST)
    send_welcome_email(user)           # slow — the user waits for the email to send
    generate_report(user)               # even slower
    return redirect("home")             # finally responds after all that
```

Realizar trabajo lento en línea hace que los usuarios esperen y corre el riesgo de que expire la solicitud. Celery lo descarga a workers en segundo plano para que la solicitud se devuelva inmediatamente.

## Definir y llamar una tarea de Celery

```python
# tasks.py — define a task
from celery import shared_task

@shared_task
def send_welcome_email(user_id):
    user = User.objects.get(id=user_id)
    send_email(user.email, "Welcome!")    # runs in a WORKER, not the web process

# in a view — QUEUE the task instead of running it inline
def register(request):
    user = create_user(request.POST)
    send_welcome_email.delay(user.id)     # .delay() queues it → returns IMMEDIATELY
    return redirect("home")                # user gets a fast response
```

El decorador `@shared_task` define una tarea; `.delay()` (o `.apply_async()`) la pone en cola para que un worker la procese de forma asincrónica — la vista no espera.

## La arquitectura

```text
Django (web) --.delay()--> BROKER (Redis/RabbitMQ) --> CELERY WORKER (processes the task)
                              (the message queue)         (separate process/machine)
```

```text
Components:
  ✓ Broker (Redis or RabbitMQ) — holds the queue of pending tasks
  ✓ Celery worker(s) — separate processes that pull and execute tasks
  ✓ Result backend (optional) — stores task results/status
Run workers separately: `celery -A myproject worker`
```

## Tareas programadas / periódicas (Celery Beat)

```python
# run tasks on a schedule (like cron) via Celery Beat
CELERY_BEAT_SCHEDULE = {
    "daily-report": {
        "task": "myapp.tasks.generate_daily_report",
        "schedule": crontab(hour=0, minute=0),     # every midnight
    },
}
```

## Características de confiabilidad

```python
@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def sync_data(self):
    try:
        do_sync()
    except Exception as exc:
        raise self.retry(exc=exc)             # automatic retries on failure
```

```text
✓ Retries with backoff (resilience against transient failures)
✓ Task persistence (queued tasks survive restarts via the broker)
✓ Scheduling (Celery Beat — periodic/cron-like tasks)
✓ Rate limiting, concurrency control, task routing/priorities
✓ Workers scale independently of web servers
```

## Por qué es importante

El procesamiento de tareas en segundo plano con Celery es conocimiento esencial para construir aplicaciones Django responsivas y escalables, ya que muchas necesidades del mundo real requieren trabajo que no debería ocurrir en línea durante una solicitud.

Comprenderlo es importante porque el problema central — descargar trabajo lento o diferido (enviar correos, procesar imágenes/archivos, generar reportes, llamar a APIs externas lentas, sincronización de datos) del ciclo solicitud-respuesta — es ubicuo en aplicaciones de producción.

Realizar tal trabajo en línea hace que los usuarios esperen, corre el riesgo de que expire la solicitud y se pierde el trabajo si falla, mientras que **Celery** te permite responder al usuario inmediatamente mientras que **workers** separados procesan el trabajo de forma asincrónica y confiable.

Más allá de la descarga asincrónica simple, Celery proporciona capacidades críticas de producción: **tareas programadas/periódicas** (mediante Celery Beat, reemplazando cron para programación a nivel de aplicación — reportes diarios, trabajos de limpieza, sincronizaciones recurrentes), **reintentos automáticos con backoff** (resiliencia contra fallos transitorios), **persistencia de tareas** (las tareas encoladas sobreviven a reinicios a través del broker, por lo que el trabajo no se pierde), y **escalado independiente** de workers desde servidores web.

Comprendre la arquitectura de Celery (el broker como Redis/RabbitMQ manteniendo la cola, workers procesando tareas, el backend de resultados), cómo definir y encolar tareas (`@shared_task`, `.delay()`), programar trabajo periódico y configurar características de confiabilidad es conocimiento valioso de nivel senior para construir sistemas Django de producción que manejen trabajo pesado o diferido gracefully.

Porque el procesamiento en segundo plano es un requisito común e importante para aplicaciones responsivas y robustas — y Celery es la solución de facto estándar en el ecosistema Django — dominarlo es una habilidad práctica y frecuentemente relevante que refleja la capacidad de arquitectar aplicaciones Django del mundo real más allá del manejo sincrónico simple de solicitudes.