آپ مضبوط بیک گراؤنڈ جابز (Celery/ARQ) کو کیسے چلاتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**مضبوط، پائیدار بیک گراؤنڈ جابز** کے لیے (FastAPI کے ہلکے `BackgroundTasks` سے آگے)، آپ ایک اصل task queue استعمال کرتے ہیں: **Celery** (قائم شدہ معیار) یا **ARQ** (ایک جدید async-native queue)۔ یہ بھاری، دوبارہ کوشش کے قابل، شیڈول شدہ کام کو الگ 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 کو queue میں ڈالتا ہے اور فوری جواب دیتا ہے؛ ایک الگ **worker** process اسے persistence اور retries کے ساتھ چلاتا ہے۔

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

## یہ اہم کیوں ہے

مضبوط بیک گراؤنڈ جابز چلانا production-grade FastAPI applications بنانے کے لیے ضروری ہے جو بھاری یا تاخیر والے کام کو قابل اعتماد طریقے سے سنبھالتے ہوں — اور یہ سمجھنا کہ کب اور کیسے ایک اصل task queue استعمال کریں، senior-level کا اہم علم ہے۔

مرکزی فیصلہ **`BackgroundTasks` کی حدود** کو پہچاننا ہے (کوئی persistence، retries، یا scheduling نہیں — صرف تیز، غیر اہم کام کے لیے ٹھیک ہے) اور جب کام پائیدار، دوبارہ کوشش کے قابل، شیڈول شدہ، بھاری، یا distributed ہو تو **Celery یا ARQ** کی طرف رجوع کریں (files/videos کو process کرنا، بڑے پیمانے پر emails بھیجنا، ڈیٹا sync کرنا، reports تیار کرنا)۔

یہ queues اہم production صلاحیتیں فراہم کرتے ہیں: **persistence** (jobs broker کے ذریعے crashes سے بچتے ہیں، اس لیے کام نہیں کھوتا)، **خودکار retries** (عارضی failures کے خلاف لچک)، **scheduling** (متوازی jobs)، اور **workers کی آزاد scaling** web servers سے۔

یہ جاننا کہ tasks کو کیسے define اور enqueue کریں (Celery کا `.delay()`، ARQ کا async-native API)، architecture (broker + workers)، اور خاص طور پر **اصل queue بمقابلہ BackgroundTasks استعمال کرنے کے وقت کا فیصلہ**، قابل قدر ہے قابل اعتماد applications بنانے کے لیے جو بھاری کام کو unload کرتے ہوں بغیر اسے کھوئے — ایک عام، اہم ضرورت جو مضبوط production systems کو نازک سے الگ کرتی ہے۔

BackgroundTasks کے ساتھ کیوں نہیں؟

Celery — tasks کو define اور queue کریں

ARQ — async-native (FastAPI کے async model کے ساتھ موافق)

اصل task queue کیا فراہم کرتا ہے

یہ اہم کیوں ہے

متعلقہ سوالات