Ever looked at a modern chat application and wondered how messages fly across the screen for everyone in real-time? I spent years taking this magic for granted until I needed to build a system that could handle thousands of conversations simultaneously for a project. The challenge of making it fast, reliable, and scalable led me down a fascinating path. Let’s build the engine behind that real-time conversation together.

The foundation of any live chat is a persistent, two-way connection between your browser and the server. This is where the WebSocket protocol shines, and FastAPI provides excellent tools to work with it. Imagine a phone line that stays open, allowing instant chatter back and forth instead of constantly hanging up and redialing.

How do we manage these open lines for hundreds or thousands of users? We start by creating a central connection manager. This object is the air traffic controller for our chat system, keeping track of who is connected and which “room” they are in.

# A simple manager to start
from fastapi import WebSocket
from typing import Dict, Set

class ConnectionManager:
    def __init__(self):
        self.active_connections: Dict[str, Set[WebSocket]] = {}

    async def connect(self, websocket: WebSocket, room_id: str):
        await websocket.accept()
        if room_id not in self.active_connections:
            self.active_connections[room_id] = set()
        self.active_connections[room_id].add(websocket)

    def disconnect(self, websocket: WebSocket, room_id: str):
        self.active_connections[room_id].discard(websocket)

    async def broadcast_to_room(self, message: str, room_id: str):
        if room_id in self.active_connections:
            for connection in self.active_connections[room_id]:
                await connection.send_text(message)

With this manager, we can accept connections and broadcast messages to everyone in a specific room. But what happens when you need more than one server? A message sent to Server A won’t reach users connected to Server B. This is a common wall developers hit when scaling.

The solution is a central message bus that all servers can talk to. Enter Redis with its Publish/Subscribe (Pub/Sub) feature. Instead of servers sending messages directly to clients, they publish them to a Redis channel. Every server subscribes to that channel and relays messages to its own connected users.

Think of it like a radio station. Each server is a radio tower, and Redis is the broadcasting studio. Here’s how you might set up a subscriber in your FastAPI app.

import json
import asyncio
import aioredis
from app.websocket.manager import connection_manager

async def listen_to_redis(room_id: str):
    redis = await aioredis.from_url("redis://localhost")
    pubsub = redis.pubsub()
    await pubsub.subscribe(f"chat_room:{room_id}")

    async for message in pubsub.listen():
        if message["type"] == "message":
            data = json.loads(message["data"])
            # Now broadcast to all local connections in this room
            await connection_manager.broadcast_to_room(
                json.dumps(data), 
                room_id
            )

Authentication is crucial. You can’t let just anyone connect. A common method is to use a secure JSON Web Token (JWT) when establishing the WebSocket connection. The client sends the token as a query parameter, and the server validates it before allowing the link to open.

What about when a user’s internet flickers? A good system expects this. Implementing a heartbeat—a regular “ping-pong” message—helps detect dead connections so we can clean them up. We also need to think about storing chat history. While Redis is great for speed, we often save messages to a database like PostgreSQL for permanence.

Putting it all together, the flow looks like this: A user connects with a valid token and joins a room. When they send a message, your server publishes it to a Redis channel. Every server instance subscribed to that channel receives it and sends it to their local users in that room. It’s fast, and it scales horizontally.

Building this system teaches you so much about state, concurrency, and fault tolerance. The feeling of sending a message and seeing it pop up instantly on another screen never gets old. It turns a complex network problem into a simple, human conversation.

Did this guide help you see the pieces of a real-time system come together? If you found it useful, please share it with a fellow developer. I’d love to hear about your own experiences or challenges in the comments below—what’s the most interesting feature you’ve had to build for a chat application?