Jak spustit robustní background jobs (Celery/ARQ)?

Question

IT Interview Practice · Accepted Answer

Pro **robustní, trvalé background jobs** (mimo lehký FastAPI `BackgroundTasks`), používáte skutečnou frontu úloh: **Celery** (etablovaný standard) nebo **ARQ** (moderní async-nativní fronta). Ty spouštějí těžké, opakovatelné, plánované úlohy v samostatných worker procesech, zálohovány brokerem jako Redis.

## Proč ne jen 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 — definování a zařazování úloh do fronty

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

Endpoint zařadí úlohu do fronty a okamžitě odpoví; samostatný **worker** proces ji provede s trvalostí a opakováním.

## ARQ — async-nativní (odpovídá FastAPI modelu async)

```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 je lehčí, async-first alternativa — přitažlivá, když je váš kód už async.

## Co poskytuje skutečná fronta úloh

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

## Proč na to záleží

Spouštění robustních background jobů je zásadní pro budování produkčních FastAPI aplikací, které spolehlivě zpracovávají těžkou nebo odloženou práci — a porozumění tomu, kdy a jak použít skutečnou frontu, je důležité znalosti na senior úrovni.

Jádrem úsudku je rozpoznání **omezení `BackgroundTasks`** (žádná perzistence, opakování či plánování — v pořádku jen pro rychlou, nekritickou práci) a dosáhnutí **Celery nebo ARQ**, když musí být práce trvalá, opakovatelná, plánovaná, těžká nebo distribuovaná (zpracování souborů/videí, odesílání hromadných e-mailů, synchronizace dat, generování sestav).

Tyto fronty nabízejí kritické produkční možnosti: **perzistence** (úlohy přežijí pády přes broker, takže se práce neztratí), **automatické opakování** (odolnost proti přechodným chybám), **plánování** (periodické úlohy) a **nezávislé škálování** workerů od webových serverů.

Vědět, jak definovat a zařazovat úlohy do fronty (Celery `.delay()`, ARQ async-nativní API), architekturu (broker + workery) a zejména **rozhodnutí, kdy použít skutečnou frontu versus BackgroundTasks**, je cenné pro navrhování spolehlivých aplikací, které odlehčují těžkou práci bez ztráty — běžný, důležitý požadavek, který rozlišuje robustní produkční systémy od křehkých.

Proč ne jen BackgroundTasks?

Celery — definování a zařazování úloh do fronty

ARQ — async-nativní (odpovídá FastAPI modelu async)

Co poskytuje skutečná fronta úloh

Proč na to záleží

Související otázky