Comment exécuter des tâches de fond robustes (Celery/ARQ) ?

Question

Accepted Answer

Pour des **tâches de fond robustes et durables** (au-delà du `BackgroundTasks` léger de FastAPI), vous utilisez une véritable file d'attente de tâches : **Celery** (la norme établie) ou **ARQ** (une file d'attente async-native moderne). Ces outils exécutent des travaux lourds, réessayables et programmés dans des processus workers séparés, soutenus par un broker comme Redis.

## Pourquoi ne pas utiliser juste BackgroundTasks ?

```text
BackgroundTasks runs in the web process → NO persistence (lost on crash), NO retries,
NO scheduling, and heavy work ties up the worker. Fine only for quick fire-and-forget.
For durable/critical/heavy/scheduled jobs → use a real task queue (Celery / ARQ).
```

## Celery — définir et mettre en file d'attente les tâches

```python
# tasks.py
from celery import Celery
celery_app = Celery("tasks", broker="redis://localhost:6379")

@celery_app.task(bind=True, max_retries=3)
def process_video(self, video_id: int):
    try:
        do_heavy_processing(video_id)        # runs in a WORKER, not the web process
    except Exception as exc:
        raise self.retry(exc=exc, countdown=60)   # automatic retry on failure
```

```python
# in a FastAPI endpoint — QUEUE the task, return immediately
@app.post("/videos/{id}/process")
def process(id: int):
    process_video.delay(id)                  # enqueue → returns at once (doesn't block)
    return {"status": "processing started"}
# run workers separately: celery -A tasks worker
```

Le endpoint met la tâche en file d'attente et répond instantanément ; un processus **worker** séparé l'exécute avec persistance et retries.

## ARQ — async-native (s'adapte au modèle async de FastAPI)

```python
# ARQ is built on asyncio — a natural fit for async FastAPI codebases
async def process_video(ctx, video_id: int):
    await do_async_processing(video_id)

# enqueue from an endpoint
await redis.enqueue_job("process_video", video_id)
```

ARQ est une alternative plus légère et async-first — attrayante quand votre codebase est déjà async.

## Ce qu'une véritable file d'attente fournit

```text
✓ Persistence — jobs survive crashes/restarts (stored in the broker)
✓ Retries with backoff — resilience against transient failures
✓ Scheduling — periodic/cron-like jobs (Celery Beat)
✓ Distribution & scaling — workers scale independently of the web servers
✓ Concurrency & rate limiting, task routing/priorities, result tracking
```

## Pourquoi c'est important

Exécuter des tâches de fond robustes est essentiel pour construire des applications FastAPI de niveau production qui gèrent les travaux lourds ou différés de manière fiable — et comprendre quand et comment utiliser une véritable file d'attente est une connaissance importante au niveau senior.

Le jugement fondamental est de reconnaître les **limites de `BackgroundTasks`** (pas de persistance, retries ou programmation — acceptable seulement pour les travaux rapides et non critiques) et de passer à **Celery ou ARQ** quand le travail doit être durable, réessayable, programmé, lourd ou distribué (traitement de fichiers/vidéos, envoi d'emails en masse, synchronisation de données, génération de rapports).

Ces files d'attente offrent des capacités critiques en production : **persistance** (les tâches survivent aux crash via le broker, donc le travail n'est pas perdu), **retries automatiques** (résilience contre les défaillances transitoires), **programmation** (tâches périodiques), et **mise à l'échelle indépendante** des workers par rapport aux serveurs web.

Savoir comment définir et mettre en file d'attente les tâches (`.delay()` de Celery, l'API async-native d'ARQ), l'architecture (broker + workers), et surtout la **décision de quand utiliser une véritable file d'attente par rapport à BackgroundTasks**, est précieux pour architecturer des applications fiables qui offloadent les travaux lourds sans les perdre — une exigence commune et importante qui distingue les systèmes production robustes des systèmes fragiles.