Real-time Communication

The Real-Time Problem

Traditional HTTP: Client requests, server responds. Client must poll for updates.

Problems:

• Client must keep asking - Client repeatedly polls server, even when no updates are available
• Wastes bandwidth (empty responses) - Most polling requests return no data, wasting network resources
• High latency (only checks periodically) - Updates are delayed until next poll, not real-time
• Server overload (many requests) - Constant polling creates unnecessary load on the server

Solution: Real-time communication - Server pushes updates to client!

---

Three Real-Time Patterns

1. WebSocket (Full-Duplex)

Bidirectional, persistent connection.

Characteristics:

• Full-duplex (both can send) - Client and server can send messages independently at any time
• Persistent connection - Connection stays open, avoiding connection overhead
• Low latency - Messages are sent immediately without HTTP request/response overhead
• Efficient (no HTTP overhead) - No HTTP headers for each message, just raw data
• More complex - Requires connection management, reconnection logic, and state handling
• Stateful (harder to scale) - Each connection maintains state, making horizontal scaling more complex

2. Server-Sent Events (SSE)

Server-to-client streaming over HTTP.

Characteristics:

• Simple (HTTP-based) - Uses standard HTTP, easy to implement and debug
• Automatic reconnection - Browser automatically reconnects if connection drops
• Works through proxies/firewalls - Uses standard HTTP, works in restricted network environments
• One-way (server to client) - Server pushes data to client, but client can’t send data back through SSE
• Not bidirectional - Client must use separate HTTP requests to send data to server
• Limited browser support (better now) - Modern browsers support SSE well, but older browsers may not

3. Long Polling

Hold request open until data available.

Characteristics:

• Works everywhere (HTTP) - Uses standard HTTP, works in any environment
• Simple to implement - Easy to add to existing HTTP-based systems
• Less efficient (many requests) - Requires many HTTP requests, each with overhead
• Higher latency - Latency depends on polling interval, not truly real-time
• Server holds connections - Server must maintain open connections, consuming resources

---

WebSocket Deep Dive

How WebSocket Works

1. Handshake (HTTP Upgrade):

GET /ws HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Server responds:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

2. Connection Established - Now bidirectional!

WebSocket Implementation

WebSocket Client

---

Server-Sent Events (SSE)

How SSE Works

Client opens HTTP connection, server streams events:

GET /events HTTP/1.1
Host: example.com
Accept: text/event-stream
Cache-Control: no-cache

Server responds with stream:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

event: message
data: Hello World

event: update
data: {"user": "John", "status": "online"}

event: message
data: Goodbye

SSE Implementation

SSE Client

---

Long Polling

How Long Polling Works

Client sends request, server holds it open:

---

Comparison: When to Use What?

Pattern	Use When	Don’t Use When
WebSocket	Bidirectional needed, low latency, high frequency	Simple one-way updates, HTTP-only environments
SSE	Server-to-client only, simple implementation, HTTP-based	Bidirectional needed, client-to-server messages
Long Polling	WebSocket/SSE not available, simple use case	High frequency, low latency needed

Decision Tree

Need bidirectional?
  Yes → WebSocket
  No → Need low latency?
    Yes → SSE
    No → Long Polling (fallback)

---

Connection Management (LLD)

Managing connections is critical:

---

Key Takeaways

🔄 WebSocket: Full-Duplex

WebSocket provides bidirectional, persistent connection. Best for chat, gaming, real-time collaboration.

📡 SSE: Simple Streaming

SSE is HTTP-based, server-to-client streaming. Simpler than WebSocket, automatic reconnection.

⏳ Long Polling: Fallback

Long polling holds requests open. Use when WebSocket/SSE not available. Less efficient but works everywhere.

🔌 Connection Management

Manage connections carefully: heartbeat, cleanup, reconnection. Critical for production systems.

---

Next Steps

• Master Rate Limiting - controlling API usage
• Review API Gateway - how real-time fits with gateways
• Learn gRPC - gRPC also supports streaming