Hvordan kører du robuste baggrundsopgaver (Celery/ARQ)?

Question

Accepted Answer

For **robuste, holdbare baggrundsopgaver** (ud over FastAPI's lette `BackgroundTasks`), bruger du en rigtig task queue: **Celery** (den etablerede standard) eller **ARQ** (en moderne async-native queue). Disse kører tungt, retry-bar, planlagt arbejde i separate worker-processer, understøttet af en broker som Redis.

## Hvorfor ikke bare 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 — definer og queue opgaver

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

Endpointet enqueue'r jobbet og svarer øjeblikkeligt; en separat **worker**-proces udfører det med persistens og retries.

## ARQ — async-native (passer til 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 er et lettere, async-først alternativ — attraktivt når dit codebase allerede er async.

## Hvad en rigtig task queue giver

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

## Hvorfor det betyder noget

At køre robuste baggrundsopgaver er afgørende for at bygge produktionsmæssige FastAPI-applikationer, der håndterer tungt eller udskudt arbejde pålideligt — og at forstå hvornår og hvordan man bruger en rigtig task queue er vigtig senior-niveau viden.

Kernedommen er at genkende **begrænsningerne ved `BackgroundTasks`** (ingen persistens, retries eller scheduling — fint kun til hurtigt, ikke-kritisk arbejde) og gå efter **Celery eller ARQ**, når arbejdet skal være holdbart, retry-bart, planlagt, tungt eller distribueret (behandling af filer/videoer, afsendelse af bulk-emails, datasynkronisering, generering af rapporter).

Disse queues tilbyder kritiske produktionsevner: **persistens** (jobs overlever nedbrud via brokeren, så arbejde går ikke tabt), **automatiske retries** (resiliens mod forbigående fejl), **scheduling** (periodiske jobs) og **uafhængig skalering** af workers fra webservere.

At vide, hvordan man definerer og enqueu'r opgaver (Celery's `.delay()`, ARQ's async-native API), arkitekturen (broker + workers) og især **afgørelsen om hvornår man skal bruge en rigtig queue versus BackgroundTasks**, er værdifuldt for at arkitekturere pålidelige applikationer, der aflaster tungt arbejde uden at miste det — et almindeligt, vigtig krav, der skelner robuste produktionssystemer fra skrøbelige systemer.