Hur kör du robusta bakgrundsjobb (Celery/ARQ)?

Question

Accepted Answer

För **robusta, långsiktiga bakgrundsjobb** (bortom FastAPIs lättviktiga `BackgroundTasks`), använder du en verklig jobbkö: **Celery** (den etablerade standarden) eller **ARQ** (en modern async-native kö). Dessa kör tung, återförsökbar, schemalagd arbete i separata worker-processer, backas upp av en broker som Redis.

## Varför inte bara 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 — definiera och köa jobb

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

Endpointen köar jobbet och svarar omedelbar; en separat **worker**-process exekverar det med persistens och återförsök.

## ARQ — async-native (passar FastAPIs async-modell)

```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 är ett lättare, async-först alternativ — tilltalande när din kodbas redan är async.

## Vad en verklig jobbkö tillhandahåller

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

## Varför det är viktigt

Att köra robusta bakgrundsjobb är väsentligt för att bygga produktionsklara FastAPI-applikationer som hanterar tung eller uppskjuten arbete tillförlitligt — och att förstå när och hur man använder en verklig jobbkö är viktig kunskap på seniornivå.

Kärnjudgementet är att känna igen **gränserna för `BackgroundTasks`** (ingen persistens, återförsök eller schemaläggning — OK endast för snabbt, icke-kritiskt arbete) och välja **Celery eller ARQ** när arbete måste vara långsiktigt, återförsökbar, schemalagd, tung eller distribuerad (bearbetning av filer/videor, massutskick av e-post, datasyning, rapportgenerering).

Dessa köer erbjuder kritiska produktionsförmågor: **persistens** (jobb överlever krascher via brokern, så arbetet går inte förlorat), **automatiska återförsök** (motståndskraft mot övergående fel), **schemaläggning** (periodiska jobb) och **oberoende skalning** av workers från webbservrar.

Att veta hur man definierar och köar jobb (Celery's `.delay()`, ARQ's async-native API), arkitekturen (broker + workers), och särskilt **beslutet om när man använder en verklig kö kontra BackgroundTasks**, är värdefullt för att arkitektera tillförlitliga applikationer som avlastar tung arbete utan att förlora det — ett vanligt, viktigt krav som skiljer robusta produktionssystem från skör ones.