How do BackgroundTasks work?

Question

Accepted Answer

FastAPI's **`BackgroundTasks`** lets you run work **after returning the response** — so the client gets a fast reply while light follow-up work (sending an email, logging, cleanup) happens in the background. It's built in and simple, for lightweight tasks.

## Using BackgroundTasks

```python
from fastapi import BackgroundTasks

def send_email(address: str, message: str):
    # slow-ish work that the client shouldn't wait for
    email_client.send(address, message)

@app.post("/signup")
def signup(user: User, background_tasks: BackgroundTasks):   # inject BackgroundTasks
    save_user(user)
    background_tasks.add_task(send_email, user.email, "Welcome!")   # queue it
    return {"message": "User created"}    # RESPONSE returns NOW; email sends AFTER
```

Inject a `BackgroundTasks` parameter and call `add_task(func, *args)`. FastAPI sends the response first, then runs the queued task(s) — so the user isn't kept waiting for the email.

## Multiple tasks and use with dependencies

```python
@app.post("/order")
def create_order(order: Order, bg: BackgroundTasks):
    bg.add_task(send_confirmation, order.email)
    bg.add_task(update_analytics, order.id)     # multiple tasks run in order, after the response
    return {"status": "created"}
```

## The crucial limitation: it's NOT for heavy/critical work

```text
BackgroundTasks runs IN THE SAME PROCESS as the web server:
  ✗ NO persistence — if the server crashes/restarts, queued tasks are LOST
  ✗ NO retries, scheduling, or distribution
  ✗ Heavy CPU work would still tie up the worker process
→ Good for: quick, non-critical, fire-and-forget tasks (emails, logging, light cleanup)
→ For heavy, critical, retryable, or scheduled jobs → use Celery / ARQ (a real task queue)
```

## When to use which

```text
BackgroundTasks → simple, lightweight, best-effort work tied to a request (no extra infra)
Celery / ARQ    → durable, retryable, scheduled, distributed jobs (needs a broker/workers)
```

## Why it matters

`BackgroundTasks` is a convenient built-in tool for the common need of doing follow-up work without making the client wait — sending a welcome email, writing a log, light cleanup — improving response times for the user.

Understanding it is useful for these everyday lightweight cases since it requires no extra infrastructure.

But the **most important point** is knowing its **limitations**: because it runs in the same process as the web server, it offers no persistence (tasks are lost on crash/restart), no retries, no scheduling, and isn't suitable for heavy or critical work.

Recognizing this boundary — using `BackgroundTasks` for quick, non-critical, fire-and-forget tasks, and a real task queue like **Celery/ARQ** for durable, retryable, scheduled, or heavy background jobs — is the key judgment that prevents the common mistake of relying on BackgroundTasks for work that must not be lost, making this important practical knowledge for building reliable applications.