nonobie — Real dev skills, explained like a friend would

What you'll learn

By the end of this chapter you will:

Run post-response work with BackgroundTasks
Decide when in-process tasks stop being enough — graduation criteria
Build a endpoint with connection management
Broadcast events to connected clients safely

The why

Not all useful work should block an HTTP response.

If sending an email, indexing a document, or emitting audit logs keeps users waiting, perceived performance drops quickly.

At the same time, realtime features like live notifications or dashboards cannot be modeled as one-shot request-response flows.

This chapter covers two complementary patterns:

deferred work after response,
persistent bidirectional realtime channels.

Core concepts: Async work and realtime channels

BackgroundTasks for lightweight post-response work

python

from fastapi import BackgroundTasks, FastAPI
 
app = FastAPI()
 
 
def send_welcome_email(email: str) -> None:
    # placeholder integration with email provider
    print(f"sent welcome email to {email}")
 
 
@app.post("/users")
def create_user(email: str, background_tasks: BackgroundTasks):
    # create user in database first
    background_tasks.add_task(send_welcome_email, email)
    return {"status": "created"}

BackgroundTasks are simple and require no external broker.

When to graduate to a queue

BackgroundTasks limitations:

task dies with process crash,
no durable retry queue,
no distributed worker scaling,
weak visibility for task .

Queue systems (Celery/RQ with Redis or RabbitMQ) add:

durable task storage,
retry policies,
delayed scheduling,
worker pools and monitoring.

WebSocket endpoint lifecycle

python

from fastapi import FastAPI, WebSocket, WebSocketDisconnect
 
app = FastAPI()
 
 
@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept()
    try:
        while True:
            message

WebSocket connections are long-lived and require explicit lifecycle management.

Connection manager for broadcast

python

from fastapi import WebSocket
 
 
class ConnectionManager:
    def __init__(self) -> None:
        self.active: set[WebSocket] = set()
 
    async def connect(self, websocket: WebSocket) ->

Track disconnected sockets and clean them up to avoid leaks.

Backpressure and observability

Operational safeguards:

cap outbound queue depth per connection,
drop or coalesce stale events,
add heartbeat/ping strategy,
track active connection count and send latency.

Realtime systems fail gradually without backpressure controls.

Delivery semantics

If an event must never be lost, route it through a durable queue first and use WebSockets as a delivery channel, not as the source of truth.

Tool choice matrix

Requirement	Better default
Fast fire-and-forget task, low criticality	BackgroundTasks
Needs retries, durability, scheduling	Queue workers (Celery/RQ)
Client must receive updates instantly	WebSockets
Works fine with periodic fetch	HTTP polling
Large fan-out events with reliability requirements	Queue + broadcast layer

Common mistakes

Mistake	Why it hurts	Better move
Using BackgroundTasks for critical payment workflow	Lost tasks on process failure	Durable queue with retries
No connection cleanup	Memory and descriptor leaks	Explicit disconnect handling
Unbounded message fan-out	stalls and latency spikes	Rate limits and backpressure policies
Blocking I/O inside websocket loop	Starved realtime connections	Use I/O and offload blocking work
Treating WebSocket as durable event log	Missed events on reconnect	Persist state/events in DB or queue

Production notes

Put reverse proxy websocket timeout settings under test.
Add per-tenant/per-user connection limits.
Instrument queue lag and task retries if you adopt workers.
Define reconnect strategy on the client side.

Practice: Prove your Mastery

beginner Challenge

4 min

Deferred email task

Add BackgroundTasks to a signup endpoint.

Input— given data

data

POST /users

Expected Output— your code should produce this

expected

Immediate response plus queued in-process task

Write your solutionCtrl+Enter to run

Ctrl+Enter

beginner Challenge

5 min

Echo websocket

Build a websocket endpoint that echoes received messages.

Input— given data

data

Text messages over /ws

Expected Output— your code should produce this

expected

Server echoes each message

Write your solutionCtrl+Enter to run

Ctrl+Enter

intermediate Challenge

6 min

Broadcast manager

Implement active connection tracking and broadcast utility.

Input— given data

data

Multiple connected clients

Expected Output— your code should produce this

expected

All active clients receive broadcast message

Write your solutionCtrl+Enter to run

Ctrl+Enter

intermediate Challenge

6 min

Queue graduation decision

Decide if an async task workload should move from BackgroundTasks to Celery.

Input— given data

data

Task failure/retry and scale requirements

Expected Output— your code should produce this

expected

Clear migration recommendation

Write your solutionCtrl+Enter to run

Ctrl+Enter

intermediate Challenge

7 min

Backpressure policy draft

Define limits and behavior for slow websocket consumers.

Input— given data

data

High-frequency event stream

Expected Output— your code should produce this

expected

Drop/coalesce strategy with monitoring metrics

Write your solutionCtrl+Enter to run

Ctrl+Enter

Interview Questions

Beginner:

"When are FastAPI BackgroundTasks enough?"

For lightweight, non-critical post-response work where occasional loss is acceptable.
"What is the key difference between HTTP and WebSocket communication?"

HTTP is request-response per call; WebSocket is persistent bidirectional connection.

Senior:

"How do you design reliable event delivery with WebSockets?"

Persist event state in durable storage/queue, use WebSocket for transport, and support replay/resync on reconnect.
"What signals indicate it is time to migrate to a queue-based worker system?"

Increasing task failures on restarts, need for retries/scheduling, growing queue lag, and need for horizontal worker scaling.

Summary

BackgroundTasks provide simple deferred execution for low-criticality work.
Durable queues are required for retryable, high-value asynchronous jobs.
WebSockets enable realtime push but demand lifecycle and backpressure controls.
Reliability comes from explicit delivery semantics, not transport alone.

Quick recall

text

BackgroundTasks -> simple in-process defer
Queue workers -> durability + retries + scale
WebSocket -> realtime bidirectional channel
Reliability needs persistence, replay, and monitoring

Self-Check Quiz

Q1 / 3

MCQ

When are FastAPI BackgroundTasks usually sufficient?

Chapter 9 — Background Tasks & WebSockets

The why

Core concepts: Async work and realtime channels

BackgroundTasks for lightweight post-response work

When to graduate to a queue

WebSocket endpoint lifecycle

Connection manager for broadcast

Backpressure and observability

Tool choice matrix

Common mistakes

Production notes

Practice: Prove your Mastery

Deferred email task

Echo websocket

Broadcast manager

Queue graduation decision

Backpressure policy draft

Interview Questions

Summary

Quick recall

Self-Check Quiz