Hvordan kjører du robuste bakgrunnsjobber (Celery/ARQ)?

Question

Accepted Answer

For **robuste, varige bakgrunnsjobber** (utover FastAPI's lettvinns `BackgroundTasks`), bruker du en ekte oppgavekø: **Celery** (den etablerte standarden) eller **ARQ** (en moderne async-innebygd kø). Disse kjører tung, gjenprøvbar, planlagt arbeid i separate arbeiderprosesser, støttet av en megler 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 køer oppgaver

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

Sluttpunktet enqueuer jobben og svarer umiddelbart; en separat **arbeider**prosess utfører den med persistering og gjenprøvinger.

## ARQ — async-innebygd (passer FastAPI's 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 er et lettere, async-først alternativ — attraktivt når kodebassen din allerede er async.

## Hva en ekte oppgavekø tilbyr

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

Å kjøre robuste bakgrunnsjobber er essensielt for å bygge produksjonsklasse FastAPI-applikasjoner som håndterer tung eller utsatt arbeid på en pålitelig måte — og å forstå når og hvordan du bruker en ekte oppgavekø er viktig seniorklasse-kunnskap.

Kjernedommen er å gjenkjenne **grensene for `BackgroundTasks`** (ingen persistering, gjenprøvinger eller planlegging — bare greit for raskt, ikke-kritisk arbeid) og å gripe til **Celery eller ARQ** når arbeid må være varig, gjenprøvbar, planlagt, tungt eller distribuert (behandling av filer/videoer, sending av masseutsendinger, datasynkronisering, generering av rapporter).

Disse køene tilbyr kritiske produksjonsmuligheter: **persistering** (jobber overlever krasj via megleren, så arbeid går ikke tapt), **automatiske gjenprøvinger** (motstandskraft mot forbigående feil), **planlegging** (periodiske jobber) og **uavhengig skalering** av arbeidere fra webservere.

Å vite hvordan du definerer og enqueuer oppgaver (Celery's `.delay()`, ARQ's async-innebygd API), arkitekturen (megler + arbeidere), og spesielt **avgjørelsen om når du skal bruke en ekte kø versus BackgroundTasks**, er verdifullt for å arkitekturere pålitelige applikasjoner som offloader tungt arbeid uten å miste det — et vanlig, viktig krav som skiller robuste produksjonssystemer fra skjøre.