Hoe voer je robuuste achtergrondtaken uit (Celery/ARQ)?

Question

Accepted Answer

Voor **robuuste, duurzame achtergrondtaken** (voorbij FastAPI's lichte `BackgroundTasks`), gebruik je een echte taakwachtrij: **Celery** (de gevestigde standaard) of **ARQ** (een moderne async-native wachtrij). Deze voeren zware, herhaalde, geplande werk uit in afzonderlijke workerprocessen, ondersteund door een broker zoals Redis.

## Waarom het belangrijk is

```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 — definieer en wachtrij taken

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

Het eindpunt zet de taak in de wachtrij en reageert onmiddellijk; een afzonderlijk **worker**proces voert het uit met persistentie en nieuwe pogingen.

## ARQ — async-native (past in FastAPI's async-model)

```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 is een lichter, async-first alternatief — aantrekkelijk wanneer je codebase al async is.

## Wat een echte taakwachtrij biedt

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

## Waarom het belangrijk is

Het uitvoeren van robuuste achtergrondtaken is essentieel voor het bouwen van productie-grade FastAPI-applicaties die zware of uitgestelde werk betrouwbaar afhandelen — en begrijpen wanneer en hoe je een echte taakwachtrij moet gebruiken, is belangrijk senior-level kennis.

De kernbeslissing is het herkennen van de **beperkingen van `BackgroundTasks`** (geen persistentie, nieuwe pogingen of planning — alleen geschikt voor snelle, niet-kritieke werk) en kiezen voor **Celery of ARQ** wanneer werk duurzaam, herhaald, gepland, zwaar of gedistribueerd moet zijn (bestanden/video's verwerken, bulke-mails verzenden, gegevenssynchronisatie, rapporten genereren).

Deze wachtrijen bieden kritieke productiemogelijkheden: **persistentie** (taken overleven crashes via de broker, dus werk gaat niet verloren), **automatische nieuwe pogingen** (veerkracht tegen voorbijgaande fouten), **planning** (periodieke taken), en **onafhankelijke schaling** van workers van webservers.

Weten hoe je taken kunt definiëren en in de wachtrij plaatsen (Celery's `.delay()`, ARQ's async-native API), de architectuur (broker + workers), en vooral de **beslissing wanneer je een echte wachtrij moet gebruiken versus BackgroundTasks**, is waardevol voor het architecteren van betrouwbare applicaties die zwaar werk aflasten zonder het kwijt te raken — een veel voorkomende, belangrijke vereiste die robuuste productiesystemen onderscheidt van fragiele systemen.