Limits of BackgroundTasks vs Celery or ARQ

WHAT THIS TESTS Whether you recognize the durability and isolation limits of FastAPI's built-in background mechanism and can articulate the threshold for adopting a broker-backed queue.

A GOOD ANSWER COVERS BackgroundTasks run inside the same Uvicorn worker that handled the request, after the response is sent, on the same event loop or thread pool. Consequences: they consume that worker's CPU and memory, so a heavy task degrades request latency for that process. They are entirely in-memory and ephemeral, meaning a deploy, restart, OOM, or crash silently drops any queued or in-flight task. There is no retry on failure, no persistence, no result backend, no visibility or monitoring, and no rate limiting or scheduling. They can also delay or be cut off by graceful shutdown. A dedicated queue such as Celery or ARQ stores jobs in a broker like Redis or RabbitMQ, runs them on separate worker processes you scale independently, and provides retries, acknowledgements, scheduling, dead-letter handling, and observability.

COMMON WRONG ANSWERS Treating BackgroundTasks as durable. Using them for long-running jobs that tie up a request worker. Assuming they survive a deploy. Believing they retry automatically on error.

LIKELY FOLLOW-UPS How do Celery and ARQ differ, and why might ARQ suit an async stack? How do you guarantee at-least-once execution? How do you monitor queue depth and failures?

ONE CONCRETE EXAMPLE Sending a non-critical analytics ping after a request is fine with BackgroundTasks. But charging a customer's card must not be lost on a restart and may need retries with backoff, so it belongs in ARQ: the endpoint enqueues a job to Redis, an ARQ worker picks it up, retries on transient failure, and records the result, all independent of the web worker's lifecycle.