Come esegui robust background job (Celery/ARQ)?

Question

IT Interview Practice · Accepted Answer

Per **robust, durable background job** (oltre il lightweight `BackgroundTasks` di FastAPI), usi una vera task queue: **Celery** (lo standard consolidato) o **ARQ** (una moderna queue async-native). Questi eseguono lavoro pesante, ritentabile, pianificato in processi worker separati, supportati da un broker come Redis.

## Perché non solo 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 — definisci e accodare task

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

L'endpoint accoda il job e risponde istantaneamente; un processo **worker** separato lo esegue con persistenza e retry.

## ARQ — async-native (si adatta al modello async di FastAPI)

```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 è un'alternativa più leggera e async-first — interessante quando il tuo codebase è già async.

## Cosa fornisce una vera task queue

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

## Perché è importante

Eseguire robust background job è essenziale per costruire applicazioni FastAPI di livello production che gestiscono lavoro pesante o differito in modo affidabile — e comprendere quando e come usare una vera task queue è conoscenza importante di livello senior.

Il giudizio principale è riconoscere i **limiti di `BackgroundTasks`** (nessuna persistenza, retry, o pianificazione — adatto solo per lavoro rapido, non critico) e ricorrere a **Celery o ARQ** quando il lavoro deve essere durevole, ritentabile, pianificato, pesante, o distribuito (elaborazione file/video, invio email in massa, sincronizzazione dati, generazione report).

Queste queue offrono capacità critiche di produzione: **persistenza** (i job sopravvivono ai crash via il broker, quindi il lavoro non viene perso), **retry automatici** (resilienza contro guasti transitori), **pianificazione** (job periodici), e **scaling indipendente** dei worker dai server web.

Sapere come definire e accodare task (`.delay()` di Celery, API async-native di ARQ), l'architettura (broker + worker), e specialmente la **decisione di quando usare una vera queue versus BackgroundTasks**, è prezioso per progettare applicazioni affidabili che scarichino lavoro pesante senza perderlo — un requisito comune e importante che distingue i sistemi robusti di produzione da quelli fragili.

Perché non solo BackgroundTasks?

Celery — definisci e accodare task

ARQ — async-native (si adatta al modello async di FastAPI)

Cosa fornisce una vera task queue

Perché è importante

Domande correlate