आप robust background jobs (Celery/ARQ) कैसे चलाते हैं?

Question

Accepted Answer

**robust, durable background jobs** के लिए (FastAPI के lightweight `BackgroundTasks` से परे), आप एक वास्तविक task queue का उपयोग करते हैं: **Celery** (स्थापित मानक) या **ARQ** (एक आधुनिक async-native queue)। ये heavy, retryable, scheduled काम को अलग worker processes में चलाते हैं, जो Redis जैसे broker द्वारा समर्थित होते हैं।

## सिर्फ 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 — tasks को define और queue करना

```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 job को enqueue करता है और तुरंत respond करता है; एक अलग **worker** process इसे persistence और retries के साथ execute करता है।

## ARQ — async-native (FastAPI के async model में फिट बैठता है)

```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 एक हल्का, async-first विकल्प है — आकर्षक जब आपका codebase पहले से ही async है।

## एक वास्तविक 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
```

## यह क्यों महत्वपूर्ण है

robust background jobs चलाना production-grade FastAPI applications बनाने के लिए आवश्यक है जो heavy या deferred काम को विश्वसनीय रूप से संभालते हैं — और कब और कैसे एक वास्तविक task queue का उपयोग करना है यह समझना महत्वपूर्ण senior-level ज्ञान है।

मुख्य निर्णय **`BackgroundTasks` की सीमाओं** को पहचानना है (कोई persistence, retries, या scheduling नहीं — केवल त्वरित, non-critical काम के लिए ठीक) और **Celery या ARQ** की ओर मुड़ना जब काम durable, retryable, scheduled, heavy, या distributed होना चाहिए (files/videos को process करना, bulk emails भेजना, data syncing, reports generate करना)।

ये queues महत्वपूर्ण production क्षमताएं प्रदान करती हैं: **persistence** (jobs broker के माध्यम से crashes से बच जाते हैं, इसलिए काम खोता नहीं), **automatic retries** (transient failures के खिलाफ resilience), **scheduling** (periodic jobs), और web servers से workers का **independent scaling**।

यह जानना कि tasks को कैसे define और enqueue करें (Celery का `.delay()`, ARQ का async-native API), architecture (broker + workers), और विशेष रूप से **कब एक वास्तविक queue बनाम BackgroundTasks का उपयोग करना है यह निर्णय**, heavy काम को बिना खोए offload करने वाले विश्वसनीय applications को architect करने के लिए मूल्यवान है — एक सामान्य, महत्वपूर्ण आवश्यकता जो robust production systems को नाजुक systems से अलग करती है।