FastAPI Background Tasks vs SQS: When Each One Wins

Every async workload looks like it needs a queue until you price out the infrastructure. For half my endpoints, FastAPI's built-in BackgroundTasks ships the feature in ten lines. For the other half, skipping SQS would eat a customer's data.

The Simple Case

If the work is idempotent, short, and fine-to-lose, BackgroundTasks wins. Sending a welcome email after signup. Invalidating a cache. Logging an analytics event. If Lambda cold-starts or the instance restarts mid-task, the user barely notices.

from fastapi import BackgroundTasks
 
@app.post('/subscribe')
async def subscribe(email: str, bg: BackgroundTasks):
    save_subscriber(email)
    bg.add_task(send_welcome_email, email)
    return {'status': 'ok'}

No queue. No worker. No dead-letter handling. The response fires immediately and the email sends after.

When You Need SQS

I reach for SQS the moment any of three conditions hit: the work takes longer than the request timeout, losing the task would harm the user, or I need to retry with backoff. A customer importing a 10MB CSV is all three.

SQS gives me durability, visibility timeouts, and dead-letter queues. My Lambda worker can fail, retry, and eventually route poison messages somewhere a human can see them. BackgroundTasks gives me none of that.

The Decision Rule

Ask: if this task vanishes, does a human need to know? If yes, queue it. If no, background it. That one question has replaced most of my architectural debate on this topic.

See the FastAPI background tasks docs for the simple path before reaching for infrastructure you might not need.