Real-Time Architecture

Real-time isn't a feature — it's an architecture decision that changes everything: how you manage connections, how you handle state, how you deploy, and how you think about data consistency. Choosing the wrong real-time pattern costs you either performance or complexity. Choosing the right one makes your app feel alive.

The Real-Time Spectrum

┌──────────────────────────────────────────────────────────────────┐
│  Technique       │ Latency    │ Direction    │ Complexity        │
│──────────────────┼────────────┼──────────────┼───────────────────│
│  Short Polling   │ High       │ Client → Srv │ Low               │
│  Long Polling    │ Medium     │ Client → Srv │ Medium            │
│  SSE             │ Low        │ Srv → Client │ Low               │
│  WebSocket       │ Very Low   │ Bidirectional│ High              │
│  WebTransport    │ Very Low   │ Bidirectional│ Very High         │
└──────────────────────────────────────────────────────────────────┘

Short Polling

useEffect(() => {
  const interval = setInterval(async () => {
    const data = await fetch('/api/notifications');
    setNotifications(await data.json());
  }, 5000);
  return () => clearInterval(interval);
}, []);

Simple. Wasteful. Every 5 seconds you hit the server whether anything changed or not. For 10,000 users polling every 5s, that's 2,000 requests/second — most returning "no changes."

Long Polling

async function longPoll() {
  try {
    const response = await fetch('/api/notifications/poll', {
      signal: AbortSignal.timeout(30_000),
    });
    const data = await response.json();
    setNotifications(prev => [...data.new, ...prev]);
  } catch (error) {
    if (error.name !== 'AbortError') {
      await new Promise(resolve => setTimeout(resolve, 3000));
    }
  }
  longPoll();
}

The server holds the connection open until there's new data or a timeout. Better than polling for low-frequency updates, but each response requires a new HTTP connection.

Server-Sent Events (SSE)

function useSSE(url: string) {
  const [data, setData] = useState(null);
 
  useEffect(() => {
    const source = new EventSource(url);
 
    source.addEventListener('notification', (event) => {
      setData(JSON.parse(event.data));
    });
 
    source.addEventListener('heartbeat', () => {
      // Connection alive
    });
 
    source.onerror = () => {
      source.close();
      setTimeout(() => {
        // Reconnect logic (EventSource auto-reconnects by default)
      }, 3000);
    };
 
    return () => source.close();
  }, [url]);
 
  return data;
}

SSE strengths:

Built-in reconnection with Last-Event-ID
Works over HTTP/2 (multiplexed, no connection limit)
Text-based, simple server implementation
Automatic browser reconnection

SSE limitations:

Server → Client only (no bidirectional communication)
Text only (no binary)
Limited to ~6 connections per domain on HTTP/1.1

When SSE Is Enough

Notifications      → SSE ✅  (server pushes, client reads)
Live scores        → SSE ✅  (server pushes updates)
Stock ticker       → SSE ✅  (server pushes prices)
Chat messages      → SSE ❌  (need to send messages too)
Collaborative edit → SSE ❌  (need bidirectional sync)
Gaming             → SSE ❌  (need low-latency bidirectional)

WebSockets

Full-duplex, persistent TCP connection. Both client and server can send messages at any time.

class WebSocketManager {
  private ws: WebSocket | null = null;
  private reconnectAttempts = 0;
  private maxReconnectAttempts = 10;
  private listeners = new Map<string, Set<Function>>();
  private messageQueue: string[] = [];
 
  connect(url: string) {
    this.ws = new WebSocket(url);
 
    this.ws.onopen = () => {
      this.reconnectAttempts = 0;
      this.flushQueue();
      this.startHeartbeat();
    };
 
    this.ws.onmessage = (event) => {
      const message = JSON.parse(event.data);
      this.listeners.get(message.type)?.forEach(fn => fn(message.payload));
    };
 
    this.ws.onclose = (event) => {
      this.stopHeartbeat();
      if (!event.wasClean) this.reconnect(url);
    };
  }
 
  send(type: string, payload: unknown) {
    const message = JSON.stringify({ type, payload });
    if (this.ws?.readyState === WebSocket.OPEN) {
      this.ws.send(message);
    } else {
      this.messageQueue.push(message);
    }
  }
 
  on(type: string, handler: Function) {
    if (!this.listeners.has(type)) this.listeners.set(type, new Set());
    this.listeners.get(type)!.add(handler);
    return () => this.listeners.get(type)?.delete(handler);
  }
 
  private reconnect(url: string) {
    if (this.reconnectAttempts >= this.maxReconnectAttempts) return;
    const delay = Math.min(1000 * 2 ** this.reconnectAttempts, 30_000);
    this.reconnectAttempts++;
    setTimeout(() => this.connect(url), delay);
  }
 
  private heartbeatTimer: ReturnType<typeof setInterval> | null = null;
 
  private startHeartbeat() {
    this.heartbeatTimer = setInterval(() => {
      if (this.ws?.readyState === WebSocket.OPEN) {
        this.ws.send(JSON.stringify({ type: 'ping' }));
      }
    }, 25_000);
  }
 
  private stopHeartbeat() {
    if (this.heartbeatTimer) clearInterval(this.heartbeatTimer);
  }
 
  private flushQueue() {
    while (this.messageQueue.length > 0) {
      this.ws?.send(this.messageQueue.shift()!);
    }
  }
}

Connection Lifecycle

Client                              Server
  │                                    │
  │──── HTTP Upgrade Request ─────────▶│
  │◀─── 101 Switching Protocols ──────│
  │                                    │
  │◀════ WebSocket Connection ════════▶│
  │                                    │
  │──── { type: "subscribe",  ────────▶│
  │       channel: "feed" }            │
  │                                    │
  │◀──── { type: "post:new",  ────────│
  │        payload: {...} }            │
  │                                    │
  │──── ping ─────────────────────────▶│
  │◀──── pong ────────────────────────│
  │                                    │
  │──── close ────────────────────────▶│
  │◀──── close ───────────────────────│

Socket.io vs Native WebSocket

Factor	Native WebSocket	Socket.io
Fallback	None	Long polling → WebSocket
Reconnection	Manual	Built-in with backoff
Rooms/namespaces	Manual	Built-in
Binary	Supported	Supported
Broadcasting	Manual	Built-in
Bundle size	0 KB (browser native)	~45 KB
Protocol overhead	Minimal	Higher (custom protocol)

Recommendation: Use native WebSocket for new projects where you control both ends. Use Socket.io when you need fallbacks for legacy environments or want rapid prototyping with rooms.

WebTransport

The next generation — built on HTTP/3 (QUIC). Supports unreliable datagrams (no head-of-line blocking), multiple streams, and lower latency than WebSocket.

const transport = new WebTransport('https://example.com/wt');
await transport.ready;
 
const writer = transport.datagrams.writable.getWriter();
await writer.write(new TextEncoder().encode('fast unreliable message'));
 
const reader = transport.datagrams.readable.getReader();
const { value } = await reader.read();

Still emerging (2024+), but ideal for gaming, live video, and latency-critical applications.

Real-Time Data Patterns

Event Sourcing on the Frontend

Instead of storing current state, store a sequence of events and derive state:

type FeedEvent =
  | { type: 'POST_ADDED'; post: Post }
  | { type: 'POST_LIKED'; postId: string; userId: string }
  | { type: 'POST_DELETED'; postId: string }
  | { type: 'COMMENT_ADDED'; postId: string; comment: Comment };
 
function feedReducer(state: FeedState, event: FeedEvent): FeedState {
  switch (event.type) {
    case 'POST_ADDED':
      return { ...state, posts: [event.post, ...state.posts] };
    case 'POST_LIKED':
      return {
        ...state,
        posts: state.posts.map(p =>
          p.id === event.postId
            ? { ...p, likeCount: p.likeCount + 1 }
            : p
        ),
      };
    case 'POST_DELETED':
      return { ...state, posts: state.posts.filter(p => p.id !== event.postId) };
    default:
      return state;
  }
}

CRDTs for Collaboration

Conflict-free Replicated Data Types allow multiple users to edit simultaneously without coordination:

┌──────────┐                           ┌──────────┐
│  User A  │                           │  User B  │
│          │                           │          │
│ "Hello"  │                           │ "Hello"  │
│    │     │                           │    │     │
│ Insert   │                           │ Insert   │
│ " World" │                           │ "!"      │
│ at pos 5 │                           │ at pos 5 │
│    │     │          ┌─────┐          │    │     │
│    └─────┼─────────▶│     │◀─────────┼────┘     │
│          │          │CRDT │          │          │
│          │          │Merge│          │          │
│    ┌─────┼──────────│     │──────────┼────┐     │
│    ▼     │          └─────┘          │    ▼     │
│"Hello    │                           │"Hello    │
│ World!"  │                           │ World!"  │
└──────────┘                           └──────────┘

Both users converge to the same state without conflict resolution logic. Libraries like Yjs and Automerge implement this:

import * as Y from 'yjs';
import { WebsocketProvider } from 'y-websocket';
 
const doc = new Y.Doc();
const provider = new WebsocketProvider('wss://collab.example.com', 'doc-123', doc);
const text = doc.getText('content');
 
text.observe(event => {
  editor.setValue(text.toString());
});
 
function handleLocalEdit(delta: string, position: number) {
  text.insert(position, delta);
}

Operational Transform (OT)

The predecessor to CRDTs, used by Google Docs:

User A: Insert 'X' at position 3
User B: Delete character at position 1
 
Server receives A first, then transforms B:
  B's position shifts: delete at position 1 (no change needed since insert was after)
 
Server receives B first, then transforms A:
  A's position shifts: insert 'X' at position 2 (since char before was deleted)

OT requires a central server for transformation. CRDTs are decentralized but use more memory.

Presence Systems

Show who's online, who's typing, who's viewing the same document:

interface PresenceState {
  userId: string;
  status: 'online' | 'idle' | 'offline';
  cursor?: { x: number; y: number };
  lastActive: number;
}
 
function usePresence(channel: string) {
  const [peers, setPeers] = useState<Map<string, PresenceState>>(new Map());
 
  useEffect(() => {
    const ws = wsManager;
    ws.send('presence:join', { channel });
 
    const unsub1 = ws.on('presence:update', (state: PresenceState) => {
      setPeers(prev => new Map(prev).set(state.userId, state));
    });
 
    const unsub2 = ws.on('presence:leave', ({ userId }: { userId: string }) => {
      setPeers(prev => {
        const next = new Map(prev);
        next.delete(userId);
        return next;
      });
    });
 
    const idleTimer = setInterval(() => {
      ws.send('presence:heartbeat', { channel });
    }, 10_000);
 
    return () => { unsub1(); unsub2(); clearInterval(idleTimer); };
  }, [channel]);
 
  return peers;
}

Notification Architecture

┌─────────────────────────────────────────────────────┐
│              Notification System                     │
│                                                     │
│  ┌─────────┐    ┌──────────────┐    ┌────────────┐ │
│  │ Backend │───▶│ Notification │───▶│  WebSocket │ │
│  │ Events  │    │ Service      │    │  Gateway   │ │
│  └─────────┘    └──────┬───────┘    └─────┬──────┘ │
│                        │                  │        │
│                        ▼                  ▼        │
│               ┌────────────────┐  ┌────────────┐  │
│               │ Push Service   │  │  Client    │  │
│               │ (FCM / APNs)  │  │  (browser) │  │
│               └────────────────┘  └─────┬──────┘  │
│                                         │         │
│                                    ┌────▼──────┐  │
│                                    │ Toast /   │  │
│                                    │ Badge /   │  │
│                                    │ Sound     │  │
│                                    └───────────┘  │
└─────────────────────────────────────────────────────┘

Client-Side Notification Manager

type NotificationType = 'info' | 'success' | 'warning' | 'error';
 
interface Notification {
  id: string;
  type: NotificationType;
  title: string;
  message: string;
  timestamp: number;
  read: boolean;
  actionUrl?: string;
}
 
const useNotificationStore = create<NotificationStore>((set, get) => ({
  notifications: [],
  unreadCount: 0,
 
  addNotification: (notification: Omit<Notification, 'id' | 'timestamp' | 'read'>) => {
    const entry: Notification = {
      ...notification,
      id: crypto.randomUUID(),
      timestamp: Date.now(),
      read: false,
    };
    set(state => ({
      notifications: [entry, ...state.notifications].slice(0, 100),
      unreadCount: state.unreadCount + 1,
    }));
  },
 
  markAsRead: (id: string) => {
    set(state => ({
      notifications: state.notifications.map(n =>
        n.id === id ? { ...n, read: true } : n
      ),
      unreadCount: Math.max(0, state.unreadCount - 1),
    }));
  },
}));

Scaling WebSockets

The Problem

WebSocket connections are stateful. A user connected to Server A can't receive messages published from Server B.

Solution: Redis Pub/Sub

┌──────────┐    ┌──────────┐    ┌──────────┐
│ WS Srv 1 │    │ WS Srv 2 │    │ WS Srv 3 │
│ (1000    │    │ (1000    │    │ (1000    │
│  conns)  │    │  conns)  │    │  conns)  │
└────┬─────┘    └────┬─────┘    └────┬─────┘
     │               │               │
     └───────────────┼───────────────┘
                     │
              ┌──────▼──────┐
              │    Redis     │
              │   Pub/Sub    │
              └─────────────┘

When Server 1 needs to broadcast to a user on Server 2, it publishes to Redis. Server 2 subscribes and forwards to the connected client.

Sticky Sessions

Alternatively, route the same user to the same server using a load balancer:

Load Balancer (hash userId → server)
  │
  ├── userId: abc → Server 1
  ├── userId: def → Server 2
  └── userId: ghi → Server 3

Simple but fragile — if Server 1 dies, all its users must reconnect and may lose messages.

Optimistic Updates in Real-Time

┌───────────────────────────────────────────────────┐
│  Optimistic Update Flow (Chat Message)            │
│                                                   │
│  1. User types message, hits send                │
│  2. Message appears immediately (optimistic)      │
│     └─ Gray checkmark (sending)                  │
│  3. Send via WebSocket to server                 │
│  4. Server confirms receipt                       │
│     └─ Single checkmark (sent)                   │
│  5. Server confirms delivery to recipient        │
│     └─ Double checkmark (delivered)              │
│  6. Recipient reads                              │
│     └─ Blue double checkmark (read)              │
│                                                   │
│  On failure at step 3/4:                         │
│     └─ Red exclamation (failed) + retry button   │
└───────────────────────────────────────────────────┘

Offline-First with Sync

┌──────────────────────────────────────────────────┐
│              Offline-First Architecture           │
│                                                  │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐  │
│  │  UI      │───▶│  Local   │───▶│  Sync    │  │
│  │  Layer   │◀───│  Store   │◀───│  Engine  │  │
│  │          │    │ (IndexedDB)│   │          │  │
│  └──────────┘    └──────────┘    └────┬─────┘  │
│                                       │        │
│                                  ┌────▼─────┐  │
│                                  │  Server  │  │
│                                  │  (when   │  │
│                                  │  online) │  │
│                                  └──────────┘  │
└──────────────────────────────────────────────────┘

Conflict Resolution Strategies

Strategy	Description	Best For
Last-write-wins	Latest timestamp wins	Simple, low-conflict data
First-write-wins	First change is preserved	Append-only data
Merge	Combine both changes	Non-overlapping fields
CRDT	Mathematically convergent	Collaborative editing
Manual	Show conflict to user	Critical data (medical, financial)

Real-time architecture is a spectrum. Start with the simplest pattern that meets your latency requirements. Polling works for dashboards. SSE works for notifications. WebSockets work for chat. CRDTs work for collaboration. The architect's job is matching the pattern to the problem — not reaching for the most complex tool every time.