Como você executa tarefas em background com Celery?

Question

Accepted Answer

**Celery** é a ferramenta padrão para executar **tarefas em background e agendadas** em Django — trabalho que não deve bloquear a requisição HTTP (enviar emails, processar arquivos, chamar APIs lentas) ou que é executado em uma agenda. Tarefas são enfileiradas e processadas de forma assíncrona por processos **worker** separados.

## O problema que Celery resolve

```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
```

Executar trabalho lento inline faz os usuários esperar e arrisca timeouts de requisição. Celery descarrega isso para workers em background para que a requisição retorne imediatamente.

## Definindo e chamando uma tarefa 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
```

O decorator `@shared_task` define uma tarefa; `.delay()` (ou `.apply_async()`) a enfileira para um worker processar de forma assíncrona — a view não espera.

## A arquitetura

```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`
```

## Tarefas agendadas / 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
    },
}
```

## Recursos de confiabilidade

```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 que isso importa

O processamento de tarefas em background com Celery é conhecimento essencial para construir aplicações Django responsivas e escaláveis, já que muitas necessidades do mundo real requerem trabalho que não deve acontecer inline durante uma requisição.

Entender isso é importante porque o problema central — descarregar trabalho lento ou diferido (enviar emails, processar imagens/arquivos, gerar relatórios, chamar APIs externas lentas, sincronização de dados) do ciclo de requisição-resposta — é onipresente em aplicações de produção.

Fazer tal trabalho inline faz os usuários esperar, arrisca timeouts de requisição e perde o trabalho se falhar, enquanto **Celery** permite que você responda ao usuário imediatamente enquanto **workers** separados processam o trabalho de forma assíncrona e confiável.

Além da simples desativação assíncrona, Celery fornece capacidades críticas de produção: **tarefas agendadas/periódicas** (via Celery Beat, substituindo cron para agendamento em nível de aplicação — relatórios diários, trabalhos de limpeza, sincronizações recorrentes), **retentativas automáticas com backoff** (resiliência contra falhas transitórias), **persistência de tarefas** (tarefas enfileiradas sobrevivem a reinicializações via o broker, então o trabalho não é perdido), e **escalabilidade independente** de workers em relação a servidores web.

Entender a arquitetura de Celery (o broker como Redis/RabbitMQ segurando a fila, workers processando tarefas, o backend de resultado), como definir e enfileirar tarefas (`@shared_task`, `.delay()`), agendar trabalho periódico e configurar recursos de confiabilidade é conhecimento valioso em nível sênior para construir sistemas Django de produção que lidam com trabalho pesado ou diferido graciosamente.

Porque processamento em background é um requisito comum e importante para aplicações responsivas e robustas — e Celery é a solução de facto no ecossistema Django — dominá-lo é uma habilidade prática e frequentemente relevante que reflete a capacidade de arquitetar aplicações Django do mundo real além do simples manuseio de requisições síncronas.