FastAPI WebSocket Real-Time Systems

Key facts, with sources

• In the JetBrains Python Developers Survey 2024, which collected responses from more than 30,000 Python developers, FastAPI usage jumped from 29% to 38%, overtaking Django (35%) and Flask (34%) as the most-used Python web framework. (JetBrains Python Developers Survey 2024)
• The 2025 Stack Overflow Developer Survey shows FastAPI at 14.8% of respondents doing extensive work with it, edging out Flask at 14.4% and Django at 12.6%. (Stack Overflow Developer Survey 2025)
• FastAPI's official documentation cites independent TechEmpower benchmarks showing FastAPI applications running under Uvicorn as one of the fastest Python frameworks available, ranked only below Starlette and Uvicorn themselves. (FastAPI official documentation)
• FastAPI surpassed Flask in GitHub stars in December 2025, reaching roughly 88,000 stars compared to Flask's 68,400. (DZone)
• Industry analysis of FastAPI's 2025 growth reports about 40% year-over-year growth in job mentions and production adoption at companies including Uber, Netflix, and Microsoft. (byteiota)

When WebSockets are the right tool

I reach for WebSockets when the server must push unprompted and the client also sends frequently: chat, multiplayer state, live cursors, order books. If data flows one way — progress updates, notifications, token streams — server-sent events are simpler, survive proxies better, and reconnect for free in browsers. And if updates arrive every thirty seconds, plain polling remains embarrassingly effective and nobody has to operate connection state.

The honest cost of WebSockets is that your servers become stateful. Deploys, autoscaling, and load balancing all get more careful once thousands of long-lived connections are pinned to specific processes. Take that cost only when bidirectional push genuinely earns it.

The connection manager pattern

The core abstraction is a manager that tracks live connections per room or channel and broadcasts to them. Keep it boring: a dict of sets, add on connect, discard on disconnect, iterate a copy when broadcasting so disconnects during iteration do not blow up the loop.

Wrap every send in error handling at the manager level — a client can vanish between your membership check and the send. On send failure, evict the connection immediately rather than letting the broken socket poison future broadcasts.

from fastapi import FastAPI, WebSocket, WebSocketDisconnect

app = FastAPI()


class ConnectionManager:
    def __init__(self) -> None:
        self.rooms: dict[str, set[WebSocket]] = {}

    async def connect(self, room: str, ws: WebSocket) -> None:
        await ws.accept()
        self.rooms.setdefault(room, set()).add(ws)

    def disconnect(self, room: str, ws: WebSocket) -> None:
        self.rooms.get(room, set()).discard(ws)

    async def broadcast(self, room: str, message: dict) -> None:
        for ws in list(self.rooms.get(room, set())):
            await ws.send_json(message)


manager = ConnectionManager()


@app.websocket("/ws/{room}")
async def room_socket(ws: WebSocket, room: str):
    await manager.connect(room, ws)
    try:
        while True:
            data = await ws.receive_json()
            await manager.broadcast(room, data)
    except WebSocketDisconnect:
        manager.disconnect(room, ws)

Authenticate at the handshake, not after

Browsers cannot set custom headers on WebSocket connections, so your normal Authorization header flow does not apply. The workable options are a short-lived, single-purpose token passed as a query parameter — never the long-lived session token, since query strings land in access logs — or cookie auth if the socket shares an origin with your web app, or an auth message as the first frame with a strict timeout.

Whatever the mechanism, validate before or immediately after accepting and close with code 1008 on failure. I authorize the room, not just the user: a valid user connecting to a conversation they do not belong to is the actual attack you are defending against, and I still find endpoints that skip that check.

Scaling past one process

The in-memory manager works until you run a second worker or a second instance — then two users in the same room can land on different processes and never see each other's messages. The standard fix is Redis pub/sub: every process subscribes to the channels for its local rooms, publishes incoming messages to Redis, and delivers whatever arrives from Redis to its local sockets.

This keeps processes stateless with respect to each other and lets you scale horizontally without sticky sessions. Persist messages to the database before publishing, not after delivery — pub/sub is fire-and-forget, and the database, not the broadcast, is your source of truth when clients reconnect and ask what they missed.

Heartbeats, backpressure, and cleanup

Dead connections do not always announce themselves — mobile clients drop off networks without a close frame, and the socket looks alive until a send fails. I run application-level heartbeats: ping every few tens of seconds, evict connections that miss a couple of pongs. Infrastructure in the middle often enforces idle timeouts anyway, so heartbeats also keep legitimate quiet connections alive.

Backpressure is the sneakier failure. A slow consumer on a busy room makes sends queue in memory; enough of them and the process dies. Give each connection a bounded outbound queue and drop or disconnect slow consumers past the limit. Losing one laggy client beats losing the process and everyone on it.

When to hire senior help

Bring in senior help when your API needs to handle real concurrency, when you are designing service boundaries and auth for the first time, or when an existing FastAPI codebase mixes sync and async code and latency is degrading. An experienced engineer can usually diagnose event-loop blocking and connection-pool misconfiguration in days, which is far cheaper than re-architecting after launch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Python — FastAPI Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Calling blocking libraries (classic SQLAlchemy sessions, requests, heavy file I/O) inside async def endpoints, which stalls the event loop and erases FastAPI's concurrency advantage
• ✕Deploying a single Uvicorn process with no process manager or worker scaling, leaving most CPU cores idle under production load
• ✕Treating the auto-generated OpenAPI docs as a versioning strategy, then breaking mobile and partner clients when response schemas change
• ✕Running large payloads through deeply nested Pydantic models on every request and response, adding serialization latency that shows up only at scale

Frequently asked questions

Sources

• JetBrains Python Developers Survey 2024
• Stack Overflow Developer Survey 2025
• FastAPI official documentation
• DZone
• byteiota