ਤੁਸੀਂ ਮਜ਼ਬੂਤ ਬੈਕਗ੍ਰਾਉਂਡ ਜਾਬਸ (Celery/ARQ) ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

**ਮਜ਼ਬੂਤ, ਟਿਕਾਊ ਬੈਕਗ੍ਰਾਉਂਡ ਜਾਬਸ** (FastAPI ਦੇ ਭਰੋਸੇਯੋਗ `BackgroundTasks` ਤੋਂ ਪਰੇ) ਲਈ, ਤੁਸੀਂ ਇੱਕ ਅਸਲ ਟਾਸਕ ਕਿਊ ਵਰਤੋ: **Celery** (ਸਥਾਪਿਤ ਮਾਪਦੰਡ) ਜਾਂ **ARQ** (ਇੱਕ ਆਧੁਨਿਕ async-ਨੈਟਿਵ ਕਿਊ)। ਇਹ ਭਾਰੀ, ਮੁੜ ਕਰਨ ਯੋਗ, ਤੋ ਅਨੁਸੂਚਿਤ ਕਾਰਜ ਨੂੰ ਵੱਖਰੀ ਵਰਕਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹਨ, ਜੋ Redis ਵਰਗੇ ਬ੍ਰੋਕਰ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ।

## ਬਸ 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 — ਟਾਸਕ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਕਤਾਰ ਬਣਾਓ

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

ਐਂਡਪੁਆਇੰਟ ਜਾਬ ਨੂੰ ਲਾਈਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਅਤੇ ਤੁਰੰਤ ਜਵਾਬ ਦਿੰਦਾ ਹੈ; ਇੱਕ ਵੱਖਰੀ **ਵਰਕਰ** ਪ੍ਰਕਿਰਿਆ ਇਸ ਨੂੰ ਸਥਿਤੀ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਦੇ ਨਾਲ ਚਲਾਉਂਦੀ ਹੈ।

## ARQ — async-ਨੈਟਿਵ (FastAPI ਦੇ 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 ਇੱਕ ਹਲਕਾ, async-ਪਹਿਲਾ ਵਿਕਲਪ ਹੈ — ਆਕਰਸ਼ਕ ਜਦੋਂ ਤੁਹਾਡਾ ਕੋਡਬੇਸ ਪਹਿਲਾਂ ਤੋਂ async ਹੈ।

## ਅਸਲ ਟਾਸਕ ਕਿਊ ਕੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ

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

## ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਮਜ਼ਬੂਤ ਬੈਕਗ੍ਰਾਉਂਡ ਜਾਬਸ ਚਲਾਉਣਾ ਉਤਪਾਦਨ-ਗ੍ਰੇਡ FastAPI ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਜੋ ਭਾਰੀ ਜਾਂ ਸਥਗਿਤ ਕਾਰਜ ਨੂੰ ਭਰੋਸੇਮੰਦ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ — ਅਤੇ ਇਹ ਸਮਝਣਾ ਕਿ ਕਦੋਂ ਅਤੇ ਕਿਵੇਂ ਅਸਲ ਟਾਸਕ ਕਿਊ ਵਰਤਣਾ ਹੈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਸੀਨੀਅਰ-ਲੈਵਲ ਗਿਆਨ ਹੈ।

ਮੁੱਖ ਫੈਸਲਾ ਹੈ `BackgroundTasks` (**ਕੋਈ ਸਥਿਤੀ, ਮੁੜ ਕੋਸ਼ਿਸ਼ ਜਾਂ ਤੋ ਨਹੀਂ — ਸਿਰਫ ਤੇਜ਼, ਗ਼ੈਰ-ਨਾਜ਼ੁਕ ਕਾਰਜ ਲਈ ਠੀਕ ਹੈ**) ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਪਛਾਣਨਾ ਅਤੇ **Celery ਜਾਂ ARQ** ਲਈ ਪਹੁੰਚਣਾ ਜਦੋਂ ਕਾਮ ਟਿਕਾਊ, ਮੁੜ ਕਰਨ ਯੋਗ, ਤੋ, ਭਾਰੀ ਜਾਂ ਵਿਤਰਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਫਾਈਲਾਂ/ਵੀਡੀਓ ਦੀ ਪ੍ਰਕਿਰਿਆ, ਬਲਕ ਈਮੇਲ ਭੇਜਣਾ, ਡਾਟਾ ਸਿੰਕ ਕਰਨਾ, ਰਿਪੋਰਟ ਜੋੜਨਾ)।

ਇਹ ਕਤਾਰਾਂ ਗਣਨਾ ਮਾਤਰ ਸਮਰਥਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ: **ਪਿਸਤ** (ਜਾਬਸ ਕ੍ਰੈਸ਼ ਦੁਆਰਾ ਬ੍ਰੋਕਰ ਦੁਆਰਾ ਬਚਾ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਕਾਮ ਕਮੀ ਨਹੀਂ ਹੁੰਦਾ), **ਆਟੋਮੈਟਿਕ ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ** (ਅਸਥਾਈ ਅਸਫਲਤਾਵਾਂ ਦੇ ਖਿਲਾਫ ਲਚਕ), **ਸਮੇਂ ਨਿਰਧਾਰਨ** (ਨਿਯਮਿਤ ਕਾਮ), ਅਤੇ **ਸਤੰਤਰ ਸਕੇਲਿੰਗ** ਵੈਬ ਸਰਵਰਾਂ ਤੋਂ ਵਰਕਰਾਂ ਦੀ।

ਜਾਨਣਾ ਕਿ ਕਿਵੇਂ ਟਾਸਕ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਕਤਾਰ ਬਣਾਉ (Celery ਦਾ `.delay()`, ARQ ਦਾ async-ਨੈਟਿਵ API), ਆਰਕੀਟੈਕਚਰ (ਬ੍ਰੋਕਰ + ਵਰਕਰ), ਅਤੇ ਖਾਸ ਤੌਰ ਉੱਤੇ **ਫੈਸਲਾ ਜੋ ਅਸਲ ਕਿਊ ਬਨਾਮ BackgroundTasks ਦੀ ਵਰਤੋਂ ਕਰਨ ਵੇਲੇ** ਮੂਲਮਾਨ ਕਿਰਤਵ ਹੈ ਭਰੋਸੇਯੋਗ ਅਰਜ਼ਾਂ ਦੀ ਆਰਕੀਟੈਕਟ ਲਈ ਜੋ ਭਾਰੀ ਕਾਮ ਤੋਂ ਬਿਨਾ ਨੁਕਸਾਨ ਦੇ ਇਸਤਕ ਕਰਦੇ ਹਨ — ਇੱਕ ਆਮ, ਮਹੱਤਵਪੂਰਨ ਲੋੜ ਜੋ ਮਜ਼ਬੂਤ ਉਤਪਾਦਨ ਸਿਸਟਮਾਂ ਨੂੰ ਕਮਜ਼ੋਰ ਲੋਕਾਂ ਤੋਂ ਅਲੱਗ ਕਰਦਾ ਹੈ।

ਬਸ BackgroundTasks ਕਿਉਂ ਨਹੀਂ?

Celery — ਟਾਸਕ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਕਤਾਰ ਬਣਾਓ

ARQ — async-ਨੈਟਿਵ (FastAPI ਦੇ async ਮਾਡਲ ਨੂੰ ਫਿੱਟ ਕਰਦਾ ਹੈ)

ਅਸਲ ਟਾਸਕ ਕਿਊ ਕੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ

ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ