Cum rulezi sarcini robuste în background (Celery/ARQ)?

Question

Accepted Answer

Pentru **sarcini robuste și durabile în background** (dincolo de `BackgroundTasks` ușor din FastAPI), folosești o coadă de sarcini reală: **Celery** (standardul stabilit) sau **ARQ** (o coadă modernă și nativă async). Acestea rulează sarcini grele, retrabile și programate în procese worker separate, susținute de un broker ca Redis.

## De ce nu doar 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 — definești și enqueueuezi sarcini

```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-ul pune sarcina în coadă și răspunde instant; un proces **worker** separat o execută cu persistență și retry-uri.

## ARQ — nativ async (se potrivește modelului async din 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 este o alternativă mai ușoară și orientată async — atractivă atunci când codul tău este deja async.

## Ce oferă o coadă de sarcini reală

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

## De ce este important

Rularea sarcinilor robuste în background este esențială pentru construirea aplicațiilor FastAPI de nivel producție care gestionează sarcini grele sau amânate în mod fiabil — și înțelegerea când și cum să folosești o coadă de sarcini reală este cunoaștere importantă de nivel senior.

Decizia principală este recunoașterea **limitărilor `BackgroundTasks`** (fără persistență, retry-uri sau programare — potrivite doar pentru sarcini rapide și necritice) și apelarea la **Celery sau ARQ** atunci când sarcina trebuie să fie durabilă, retrabilă, programată, grea sau distribuită (procesarea fișierelor/videoclipurilor, trimiterea emailurilor în masă, sincronizarea datelor, generarea rapoartelor).

Aceste cozi oferă capacități critice de producție: **persistență** (sarcinile supraviețuiesc blocărilor prin broker, deci munca nu se pierde), **retry-uri automate** (reziliență împotriva defecțiunilor tranzitorii), **programare** (sarcini periodice) și **scalare independentă** a worker-ilor în raport cu serverele web.

Cunoașterea cum să definești și enqueueuezi sarcini (`.delay()` al Celery, API nativ async al ARQ), arhitectura (broker + worker-i) și în special **decizia când să folosești o coadă reală versus BackgroundTasks**, este valoroasă pentru arhitectarea aplicațiilor fiabile care externalizează sarcini grele fără să le piardă — o cerință comună și importantă care diferențiază sistemele de producție robuste de cele fragile.