Für robuste, dauerhafte Hintergrund-Jobs (über FastAPIs leichte BackgroundTasks hinaus) verwendest du eine echte Task-Queue: Celery (der etablierte Standard) oder ARQ (eine moderne async-native Queue). Diese führen schwere, wiederholbare, geplante Arbeiten in separaten Worker-Prozessen aus, unterstützt durch einen Broker wie Redis.
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).
# 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
# 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
Der Endpoint reiht den Job ein und antwortet sofort; ein separater Worker-Prozess führt ihn mit Persistierung und Wiederholungen aus.
# 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 ist eine leichtere, async-first Alternative — attraktiv, wenn deine Codebasis bereits async ist.
✓ 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
Robuste Hintergrund-Jobs auszuführen, ist essentiell für den Aufbau von produktionsreifen FastAPI-Anwendungen, die schwere oder aufgeschobene Arbeiten zuverlässig bewältigen — und das Verständnis, wann und wie man eine echte Task-Queue nutzt, ist wichtiges Wissen auf Senior-Niveau.
Die grundlegende Überlegung besteht darin, die Grenzen von BackgroundTasks zu erkennen (keine Persistierung, Wiederholungen oder Planung — nur für schnelle, unkritische Aufgaben geeignet) und zu Celery oder ARQ zu greifen, wenn Arbeit dauerhaft, wiederholbar, geplant, schwer oder verteilt sein muss (Datei-/Videoverarbeitung, Massen-E-Mails versenden, Datensynchronisierung, Berichte generieren).
These Queues bieten kritische Produktionsfähigkeiten: Persistierung (Jobs überstehen Abstürze via Broker, daher geht Arbeit nicht verloren), automatische Wiederholungen (Resilienz gegen vorübergehende Fehler), Planung (periodische Jobs) und unabhängige Skalierung von Workern von Web-Servern.
Zu wissen, wie man Tasks definiert und einreiht (Celery's .delay(), ARQ's async-native API), die Architektur (Broker + Worker) und besonders die Entscheidung, wann man eine echte Queue versus BackgroundTasks nutzt, ist wertvoll für die Architektur zuverlässiger Anwendungen, die schwere Arbeit auslagern, ohne sie zu verlieren — eine häufige, wichtige Anforderung, die robuste Produktionssysteme von fragilen unterscheidet.