Foundations · Phase 1: Foundations
Network Protocols & Real-Time Communication Paradigms
Compare TCP, UDP, QUIC (HTTP/3), gRPC Protocol Buffers, WebSockets, Server-Sent Events, and Long Polling for high-performance and real-time architectures.
Primary specification: RFC 9000: QUIC - A UDP-Based Multiplexed and Secure Transport
Lesson 2 of 33
1d streakThe Architectural Question
Developers default to polling or raw WebSockets for all real-time requirements, causing server file descriptor exhaustion and high mobile battery drain.
Core Engineering Objectives
- TCP flow control, sliding window, slow-start, and head-of-line blocking vs UDP datagrams
- HTTP/1.1 vs HTTP/2 binary multiplexing vs HTTP/3 QUIC independent streams over UDP
- Bi-directional WebSockets vs uni-directional Server-Sent Events (SSE) vs Short/Long polling
1. What is it & Why it Matters
Network protocols govern how distributed systems transmit bytes across the wire. Selecting the optimal protocol dictates latency floors, connection overhead, packet loss recovery, and real-time streaming capabilities.
Why it matters in System Design
2. Transport Layer: TCP vs. UDP vs. QUIC
| Protocol | Handshake Overhead | Ordering & Reliability | Head-of-Line (HoL) Blocking | Best Use Case |
|---|---|---|---|---|
| TCP | 1 RTT handshake (SYN, SYN-ACK, ACK) + 1-2 RTT for TLS | Strictly ordered, guaranteed delivery via retransmissions | Yes: 1 dropped packet stalls entire connection stream in OS kernel | Web browsing, file transfer, transactional APIs |
| UDP | 0 RTT (connectionless datagrams) | Unreliable: packets may drop, duplicate, or arrive out of order | No: packets are completely independent | Live video streaming, gaming state broadcast, DNS lookups, WebRTC |
| QUIC (HTTP/3) | 0-1 RTT (combines transport & TLS 1.3 handshake over UDP) | Reliable delivery with independent stream ordering | Transport-level stream blocking is reduced; connection-level congestion can still affect streams | Mobile web apps, flaky wireless networks, modern CDNs |
3. Application Protocols: HTTP Evolution and gRPC
- 01HTTP/1.1: Text-based, synchronous request-response. Suffers from HTTP head-of-line blocking: each TCP connection handles only one request at a time, requiring browser connection pooling (6 connections per host).
- 02HTTP/2: Binary framing, multiplexes multiple virtual streams over a single TCP connection, supports header compression (HPACK) and server push. Still vulnerable to TCP packet-loss head-of-line blocking.
- 03HTTP/3 (QUIC): Replaces TCP with QUIC over UDP. Eliminates transport head-of-line blocking and supports connection migration (maintains active downloads when client switches from Wi-Fi to cellular).
- 04gRPC: RPC framework commonly used with HTTP/2 and Protocol Buffers. It provides generated types, streaming, and deadline propagation; benchmark it against alternatives for the actual payload and network.
Architectural Boundary · Do Not Confuse
REST over HTTP/1.1 (JSON text payloads)
gRPC over HTTP/2 (Protocol Buffer binary payloads)
REST/JSON is human-readable and universally supported by browsers, making it the standard for public APIs. gRPC is compact, CPU-efficient, and multiplexed, making it the gold standard for high-volume internal microservice RPCs.
4. Real-Time Web: WebSockets vs. SSE vs. Polling
| Technology | Directionality | Transport Protocol | State Overhead on Server | Optimal Workload |
|---|---|---|---|---|
| Short / Long Polling | Client → Server | Standard HTTP | Low (stateless requests, but high connection churn) | Legacy systems, low-frequency updates (> 30s) |
| Server-Sent Events (SSE) | Server → Client (1-way) | HTTP/2 streaming | Low: runs over standard HTTP, native browser reconnection | Stock tickers, sports scores, AI token generation, push notifications |
| WebSockets | Bidirectional (Full Duplex) | TCP upgrade (ws://) | High: server must maintain persistent state machine and heartbeats per socket | Multiplayer gaming, collaborative document editing, real-time chat |
Use it when
Consider Server-Sent Events when updates are only server-to-client and ordinary HTTP infrastructure is valuable. Browsers reconnect automatically, but the application still needs event IDs, replay, authorization, and failure handling.
Reconsider when
Use WebSockets when true bidirectional, low-latency client-to-server messaging is required (e.g., chat typing indicators, gaming controller inputs).
5. Protocol Selection Cheat Sheet for Interviews
- 01Public Web / Mobile Client → API: HTTP/2 or HTTP/3 HTTPS with JSON or Protobuf.
- 02Internal Microservice → Microservice: gRPC with Protocol Buffers and client-side load balancing.
- 03Live Chat / Multiplayer Game: WebSockets for full-duplex bidirectional messaging.
- 04Dashboard / LLM Output Streaming: Server-Sent Events (SSE).
- 05Video / Audio Conferencing: WebRTC over UDP.
6. Active Recall Checkpoint
Active Recall Checkpoint
Why does HTTP/2 still suffer from Head-of-Line (HoL) blocking despite supporting stream multiplexing, and how does HTTP/3 solve it?
Hint: Think about the difference between application-layer multiplexing and transport-layer TCP packet delivery.
Show answer & explanation
HTTP/2 multiplexes multiple streams over a single Layer 4 TCP connection. Because TCP enforces strictly ordered byte delivery, if a single IP packet drops, the OS kernel pauses delivery of all multiplexed streams until the lost packet is retransmitted. HTTP/3 replaces TCP with QUIC over UDP, tracking retransmissions independently per stream so loss recovery is ordered per stream; shared congestion control and network conditions can still affect the connection.
Production Postmortem & Verification
Production Incident Postmortem
- Trigger / Setup: A news notification service connects 500,000 mobile clients over persistent bidirectional WebSockets for occasional 1-way breaking alerts.
- Production Symptom: Server clusters consume 80GB of RAM purely maintaining idle WebSocket state machines and heartbeats, crashing the edge tier.
- Root Cause & Fix: Unidirectional alerts should leverage HTTP/2 Server-Sent Events or mobile push networks (FCM/APNS) rather than stateful WebSockets.
Acceptance Criteria & Outcomes
- Contrast TCP handshakes and packet loss recovery with UDP zero-connection delivery.
- Explain how HTTP/3 QUIC eliminates TCP head-of-line blocking across mobile network handovers.
- Select the optimal protocol (WebSockets, SSE, gRPC, Long Polling) based on directionality, multiplexing, and reconnection constraints.
Architectural & Technical Interview Review
Core FAANG Interview Questions
Q01How do you justify introducing Network Protocols & Real-Time Communication Paradigms into a high-scale production architecture?Click to reveal model answer →Hide answer ↑Requirements & Design Brief
Introduce Network Protocols & Real-Time Communication Paradigms only when measured scale, data size, or failure boundaries exceed single-node capacity. State the exact bottleneck, evaluate operational overhead, and verify that the trade-offs justify the added moving parts.
Q02What is the primary trade-off and hidden operational cost of Network Protocols & Real-Time Communication Paradigms?Click to reveal model answer →Hide answer ↑Architecture Trade-offs
It improves scalability and availability, but introduces network hops, serialization overhead, and eventual consistency or coordination complexity.
Q03How do you handle catastrophic failure or dependency degradation in Network Protocols & Real-Time Communication Paradigms?Click to reveal model answer →Hide answer ↑Failure Review & Recovery
Implement connect/read timeouts, exponential backoff with jitter, and fallback defaults so downstream degradations do not cause cascading outages.
Production Pitfalls & Anti-Patterns
Critical Failure Anti-Patterns
Premature Distributed Complexity
Scattering distributed components before identifying concrete write, read, or storage limits creates accidental points of failure and operational debt.
Production Mitigation: Start with the simplest modular design that satisfies requirements, evolving it only as measured constraints dictate.
Unbounded Retries and Cascading Storms
When a dependency degrades, immediate synchronized retries multiply downstream traffic, turning a minor slowdown into a total fleet outage.
Production Mitigation: Enforce strict retry budgets, exponential backoff, and full randomized jitter on all client calls.
Neglecting Observability and Metrics
Deploying architecture without distributed tracing or p99 tail latency alerts leaves engineers blind when partial partitions occur.
Production Mitigation: Export metrics for request rate, error rate, p95/p99 duration, and saturation at every service boundary.