Real-time System Design

Real-time communication protocols, architectural patterns, and scaling for live data delivery

85 minutes

12Detailed Sections

Senior Level

Long polling: client repeatedly requests server; wasteful but works everywhere. Server-Sent Events (SSE): server pushes updates over HTTP; unidirectional (client cannot send).

Works with proxies. WebSocket: upgrades HTTP to persistent bidirectional connection; lower overhead.

Binary or text frames. Supports custom heartbeats.

Choice: polling for simple apps, SSE for server->client updates, WebSocket for interactive apps. Latency: polling (seconds), SSE (milliseconds), WebSocket (milliseconds).

Scalability: WebSocket requires persistent connections (more memory). Real-world: Slack uses WebSocket; Twitter uses both; financial apps use WebSocket for low-latency updates.

Key Takeaways

Long Polling: Client repeatedly asks server; simple, high overhead, high latency

Server-Sent Events (SSE): Server pushes unidirectional; works with proxies

WebSocket: Bidirectional persistent connection; lowest latency, persistent overhead

Latency: Polling (seconds), SSE/WebSocket (milliseconds)

Memory Cost: WebSocket requires open connection per user (~1-5KB)

Best Choice: Polling for simple, SSE for updates, WebSocket for interactive

Visual Diagram

Polling: Client asks repeatedly
SSE: Server pushes to client
WebSocket: Client <-> Server bidirectional

All Tutorials Practice Questions

Real-time System Design

Table of Contents

Real-time Communication Protocols: WebSockets, SSE, Polling

Key Takeaways

Visual Diagram

Deep Dive: Long Polling

Deep Dive: Server-Sent Events (SSE)

Deep Dive: WebSockets

Deep Dive: QUIC & HTTP/3

Real-time Messaging Architecture and Patterns

Presence Systems: Tracking Online/Offline Status

Fan-out Strategies: Push vs Pull Models

WebRTC for Peer-to-Peer Communication

Collaborative Editing: Operational Transform and CRDT

Scaling WebSocket Connections and Operational Patterns

Case Studies: Real-time Collaboration at Scale