Bird
Raised Fist0

HTTP 1.1 vs HTTP 2 vs HTTP 3 - What Changed and Why It Matters

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
HTTP 1.1 vs HTTP 2 vs HTTP 3 - What Changed and Why It Matters
Understanding the evolution of HTTP protocols to optimize web performance and reliability at scale
mediumNetworking and ProtocolsFreq: common
⚙️
Functional Requirements
  • Support multiplexed concurrent requests over a single connection to reduce latency
  • Enable header compression to reduce redundant metadata overhead
  • Allow server push to proactively send resources without explicit client requests
  • Improve connection reliability and reduce connection setup latency
  • Support prioritization of requests to optimize resource loading order
  • Maintain backward compatibility or graceful fallback to older HTTP versions
📊
Non-Functional Requirements
  • Handle at least 2 billion daily active users (DAU) with peak QPS of 925K requests/sec
  • Achieve 99.99% availability for web content delivery
  • Maintain 100ms P99 latency for initial page load requests
  • Reduce bandwidth overhead by at least 20% compared to HTTP 1.1
  • Minimize connection setup time to under 50ms on average
❓
Clarifying Questions to Ask
  • What is the expected client environment diversity (browsers, devices)?
  • Are we optimizing primarily for mobile networks or data center environments?
  • Is backward compatibility with HTTP 1.1 mandatory or can we require HTTP 2+?
  • What are the security requirements related to transport layer encryption?
  • Should the design consider HTTP/3 adoption challenges like UDP firewall traversal?
  • What is the expected average and peak number of concurrent connections per client?
Out of Scope
✗ Designing the full web server or CDN architecture
✗ TLS certificate management and cryptographic algorithm design
✗ Application-layer caching strategies beyond protocol-level optimizations
✗ Detailed browser rendering engine internals
📌
Assumptions
  • 2 billion DAU generating 40 HTTP requests per user per day
  • Average request size (headers + payload) is 100 bytes
  • Peak traffic occurs during 4 hours daily, representing 50% of total requests
  • Retention of logs and metrics for 7 days with 3x replication
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 requests/sec
peak write qps925,926 × 0.5 × (86400 / 14400) = 3,703,704 requests/sec
read qpsAssuming 3 reads per write, 3 × 925,926 = 2,777,778 requests/sec
💾
Storage Estimate
daily storage2B × 40 × 100 bytes = 8 TB/day
retention 7 days8 TB × 7 = 56 TB
with replication 3x56 TB × 3 = 168 TB total storage
🖥️
Server Estimate
web serversAssuming 10K req/sec per server, need 370 web servers at peak
load balancersAssuming 100K req/sec per load balancer, need 37 load balancers
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |   Client (App) |
          +-------+--------+
                  | HTTP/1.1,2,3
                  v
          +-------+--------+
          | Load Balancer  |
          +-------+--------+
                  |
                  v
          +-------+--------+
          | Web Servers    |
          +-------+--------+
                  |
                  v
          +-------+--------+
          | Backend APIs   |
          +----------------+
🧩
Components
Client Browser/HTTP Client
Initiates HTTP requests using HTTP/1.1, HTTP/2, or HTTP/3 protocols
Why thisModern browsers support HTTP/2 multiplexing and HTTP/3 QUIC transport for reduced latency and improved reliability
Why notLegacy clients limited to HTTP/1.1 lack multiplexing and incur head-of-line blocking
Load Balancer (e.g., Envoy, NGINX)
Distributes incoming HTTP requests to web servers, terminates TLS, and supports HTTP/2 and HTTP/3 protocols
Why thisEnvoy supports HTTP/3 with QUIC and HTTP/2 multiplexing natively, enabling protocol negotiation and connection management
Why notClassic TCP load balancers like HAProxy lack native HTTP/3 support and QUIC termination
Web Servers (e.g., NGINX, Apache with HTTP/2 and HTTP/3 modules)
Handles HTTP requests, supports multiplexing streams, header compression, and server push
Why thisNGINX supports HTTP/2 HPACK header compression and HTTP/3 QUIC transport for improved performance
Why notOlder HTTP/1.1-only servers cause head-of-line blocking and higher connection overhead
QUIC Transport Layer
Provides UDP-based multiplexed, encrypted transport with 0-RTT connection establishment for HTTP/3
Why thisQUIC reduces connection setup latency and eliminates TCP head-of-line blocking by multiplexing streams over UDP
Why notTCP used in HTTP/1.1 and HTTP/2 suffers from HOL blocking and slower handshake
HPACK / QPACK Header Compression
Compresses HTTP headers to reduce redundant metadata in HTTP/2 and HTTP/3
Why thisHPACK (HTTP/2) and QPACK (HTTP/3) reduce bandwidth and improve latency by compressing repetitive headers efficiently
Why notNo compression in HTTP/1.1 leads to large header overhead and wasted bandwidth
🔄
Data Flow
1
Client → Load Balancer
Client initiates HTTP request using negotiated protocol (HTTP/1.1, 2, or 3)
Protocol negotiation via ALPN during TLS handshake
2
Load Balancer → Web Server
Load balancer routes request, terminates TLS, and forwards multiplexed streams
Supports HTTP/2 multiplexing or HTTP/3 QUIC streams
3
Web Server → Backend APIs
Web server processes request, may push resources proactively
Server push reduces client round trips
4
Backend APIs → Web Server
Backend returns response data
Response streams multiplexed back to client
5
Web Server → Load Balancer
Web server sends compressed headers and payload over multiplexed streams
HPACK/QPACK header compression reduces overhead
6
Load Balancer → Client
Load balancer forwards response over HTTP/2 or HTTP/3 connection
QUIC transport enables 0-RTT resumption and reduced latency

Practice

(1/5)
1. In the digital wallet system's transaction processing flow, at Step 4 the Ledger Service applies the debit and credit entries. What happens if the Ledger Service detects a mismatch in the double-entry records at this step?
easy
A. The Ledger Service retries the transaction indefinitely until the entries match
B. The Ledger Service marks the transaction as failed and triggers an alert for manual reconciliation
C. The Ledger Service ignores the mismatch and commits the debit entry only
D. The Ledger Service rolls back the entire transaction and deletes all related entries

Solution

  1. Step 1: Understand Ledger Service's double-entry validation

    The Ledger Service enforces double-entry consistency; mismatches indicate data corruption or bugs.

  2. Step 2: Evaluate failure handling

    Retrying indefinitely (A) risks blocking; ignoring mismatch (C) breaks accounting; deleting entries (D) risks data loss. Marking failed and alerting (B) enables safe manual reconciliation.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Mismatch triggers failure mark and alert -> safe reconciliation [check]
Hint: Mismatch triggers failure mark and alert, not silent retry [OK]
Common Mistakes:
2. A notification system must handle 1 million notification writes per second and fan out to millions of devices asynchronously. Which component best decouples the write load from delivery workers to ensure durability and scalability?
easy
A. Use a simple HTTP REST API to synchronously send notifications to all devices
B. Use a relational database with sharded tables to store notifications and poll for delivery
C. Use an in-memory cache like Redis to store notifications and push directly to devices
D. Use a distributed message queue like Kafka partitioned by user ID for ordered, durable fan-out

Solution

  1. Step 1: Identify the role of the message queue

    Kafka provides durable, partitioned logs that decouple producers from consumers, enabling high write throughput and ordered delivery per user.

  2. Step 2: Evaluate other options

    Relational DB polling (A) can't handle 1M writes/sec efficiently; Redis (C) lacks durability and persistence guarantees; synchronous HTTP (D) blocks on delivery and doesn't scale.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka partitions by user ID -> durable, ordered fan-out [check]
Hint: Kafka partitions decouple writes from delivery at scale [check]
Common Mistakes:
3. Without the automated rollback system, what exactly breaks when a misconfiguration causes a route leak?
medium
A. The system silently drops all BGP updates, causing network partition
B. Route leak detection alerts flood the monitoring system but traffic continues normally
C. The system automatically quarantines all routes, causing a complete service outage
D. Alice's traffic is routed incorrectly; operators must manually detect and fix the leak, causing prolonged outages

Solution

  1. Step 1: Trace failure without rollback

    Misconfigurations propagate incorrect routes; without rollback, manual detection delays fix.

  2. Step 2: Eliminate other failure modes

    Silent drops (A) don't occur; automatic quarantine (C) would cause total outage, not typical; alert floods (D) don't prevent traffic misrouting.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Manual fix delays cause prolonged incorrect routing [check]
Hint: No rollback means manual fix delays outages [check]
Common Mistakes:
4. If the Bloom filter component is removed from the system, what exact failure occurs during key lookups?
medium
A. Every key lookup hits the backend, causing increased latency and possible backend saturation
B. The system returns false negatives, missing existing keys due to lack of filtering
C. Backend database rejects all queries due to overload, causing 503 errors
D. The system returns false positives, incorrectly indicating keys exist

Solution

  1. Step 1: Understand Bloom filter removal impact

    Without Bloom filters, no pre-filtering occurs, so all lookups go to backend.

  2. Step 2: Analyze failure modes

    Backend overload (A) is possible but not guaranteed. Increased latency (B) is true but not a failure mode. False positives (D) come from Bloom filters, not their absence. False negatives (C) occur if system relies on Bloom filter to avoid missing keys.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without Bloom filter, system risks missing keys due to no probabilistic filtering [check]
Hint: No Bloom filter means missing keys, false negatives appear [check]
Common Mistakes:
5. At 10x scale, which component in the distributed API rate limiter is most likely to fail first and why?
hard
A. Centralized logging service, because it cannot handle the increased write volume
B. API gateway, because it cannot maintain connections for all clients simultaneously
C. Distributed Counter cluster, because sharding limits cause hot partitions for popular users
D. Edge caches, because their local memory limits prevent storing counters for all users

Solution

  1. Step 1: Analyze component scalability

    Edge caches store counters in memory per user; memory is limited and grows with user count.

  2. Step 2: Compare bottlenecks

    Logging (A) can be scaled with partitioning; Distributed Counter (C) sharding mitigates hot spots; API gateway (D) scales horizontally. Edge caches (B) hit memory limits first, causing eviction or failures.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Edge caches fail first due to fixed local memory limits [check]
Hint: Edge caches limited by memory, fail before scalable components [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard