WebSocket, Server-Sent Events (SSE) & Long Polling
The Gateway Restart That DDOSed the Chat Fleet
Test your architecture intuition: Pitch a 7-axis solution, survive two aggressive reviewer objections, and inspect the staff-level Teacher Gold Answer.
1. What It Is & Why It Exists
The Core Problem: Real-Time Server-to-Client Push
Standard HTTP/1.1 is inherently request-response: the server cannot push data to a client without the client explicitly initiating a request.
- Short Polling (Anti-Pattern): The client queries
GET /notificationsevery 1 second. When updates are rare, most responses return empty arrays ([]), wasting bandwidth, request headers, and CPU cycles on both sides. - Long Polling (Hanging HTTP): The client opens an HTTP request that the server holds open until new data arrives. Each push ends that request, so the client must immediately issue a new one; with keep-alive the TCP/TLS connection is reused, but every cycle still re-sends full request headers and cookies, occupies a server worker while it hangs, and leaves a gap between responses in which events queue up.
The First-Principles Solution: Persistent Streaming Protocols
Persistent real-time protocols establish long-lived TCP/HTTP connections, allowing servers to stream events to clients as soon as they happen, with no per-event request; delivery latency is then set mostly by the network path.
Synthesizing vector architecture diagram...
2. Comprehensive Protocol Comparison Matrix
| Protocol | Directionality | Transport Layer | Framing Overhead | Native Reconnection | Firewall & Proxy Traversal | Best Production Fit |
|---|---|---|---|---|---|---|
| WebSocket | Full-Duplex (Bi-directional) | TCP (ws://, wss://) | 2–14 Bytes (client-to-server frames add a 4-byte mask) | Application-level logic | May require proxy upgrade headers (Connection: Upgrade) | Instant messaging, trading order books, interactive whiteboards |
| Server-Sent Events (SSE) | Uni-directional (Server Client) | HTTP/2 or HTTP/1.1 (text/event-stream) | UTF-8 text framing | Automatic native browser retry (Last-Event-ID) | Good (plain HTTPS on port 443); turn off proxy buffering, and send a comment line every ~15 s so idle-dropping proxies keep the stream open | LLM token streaming (ChatGPT), live score updates, metric dashboards |
| Long Polling | Half-Duplex (Emulated push) | HTTP Request/Response | Full HTTP headers on every poll cycle | Application-level loop | Flawless | Fallback for legacy corporate firewalls blocking WebSockets |
| WebTransport (QUIC) | Multi-Stream Full-Duplex | UDP / QUIC | Small QUIC stream and datagram frame headers | Application-level (QUIC connection migration survives a network change, not a dropped session) | Needs UDP 443, which some networks block | Next-gen real-time audio/video metadata and gaming |
3. Distributed WebSocket Gateway Architecture & Routing Backplane
In a clustered environment with multiple gateway servers, Client 1 is connected to Gateway A, while Client 2 is connected to Gateway B. When Client 1 sends a message to Client 2:
Synthesizing vector architecture diagram...
Follow Alice's message from the top. Alice's socket is on gateway A, but Bob's is on gateway B, and gateway A cannot write to a connection held by another server. So gateway A first looks up where Bob is connected in DynamoDB (1), then publishes the message to Redis Pub/Sub (2), which delivers it to every gateway subscribed to Bob's channel (3), and gateway B pushes it down Bob's WebSocket (4). The Pub/Sub backplane is what lets a stateful fleet scale out: any gateway can reach any user, while each connection stays pinned to one server.
DynamoDB Connection Registry Schema
PK = USER#<user_id>,SK = CONN#<connection_id>- Attributes:
gateway_ip,connected_at,ttl(Time-To-Live expiration timestamp).
Unlock Complete Architecture & Production Runbooks
You have explored the free architectural preview (~48%). Spend 1 Coin to unlock the remaining 4 production deep-dive sections for a full 24 hours.