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
▶
Request Trace
Step 1/5
Client Browser/HTTP Client

Sends HTTP request

Client initiates request using HTTP/1.1, HTTP/2, or HTTP/3 protocol

Protocol:HTTP/1.1 or HTTP/2 or HTTP/3
BeforeClient has user request ready to send over network
AfterRequest is serialized and sent over network using selected HTTP version
Load Balancer (Envoy, NGINX)

Receives and forwards request

Load balancer accepts request and forwards it to web server preserving protocol

Protocol:HTTP/1.1 or HTTP/2 or HTTP/3
BeforeLoad balancer is listening for incoming HTTP requests
AfterRequest forwarded to web server maintaining protocol semantics
Web Servers (NGINX, Apache with HTTP/2 and HTTP/3 modules)

Processes HTTP request

Web server parses request, applies HPACK/QPACK if HTTP/2 or HTTP/3

Protocol:HTTP/1.1 or HTTP/2 or HTTP/3
BeforeWeb server awaits incoming request with protocol-specific framing
AfterRequest headers decompressed if HTTP/2 or HTTP/3; request ready for app logic
HPACK / QPACK Header Compression

Compresses or decompresses headers

Headers compressed (HTTP/2) or QPACK compressed (HTTP/3) to reduce overhead

Protocol:HPACK for HTTP/2, QPACK for HTTP/3
BeforeHeaders are in plain text or compressed form depending on protocol
AfterHeaders are efficiently encoded or decoded for transmission
QUIC Transport Layer

Transports HTTP/3 frames

Uses UDP-based QUIC for multiplexed, low-latency transport in HTTP/3

Protocol:QUIC (UDP)
BeforeHTTP/3 frames ready for transport over network
AfterFrames delivered with reduced latency and improved multiplexing over UDP
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│   Client Browser/HTTP Client  │
└───────────────┬───────────────┘
                │ HTTP/1.1 or HTTP/2 or HTTP/3
                ▼
┌───────────────────────────────┐
│ Load Balancer (Envoy, NGINX)  │
└───────────────┬───────────────┘
                │ HTTP/1.1 or HTTP/2 or HTTP/3
                ▼
┌───────────────────────────────┐
│ Web Servers (NGINX, Apache)   │
│ with HTTP/2 and HTTP/3 modules│
└───────────────┬───────────────┘
                │
                │
                ▼
       ┌───────────────────────┐
       │ HPACK / QPACK Header  │
       │ Compression           │
       └─────────────┬─────────┘
                     │
                     │
                     ▼
             ┌───────────────────┐
             │ QUIC Transport    │
             │ Layer             │
             └───────────────────┘
Design Rationale

This architecture diagram illustrates the evolution from HTTP/1.1 to HTTP/2 and HTTP/3. The client browser sends requests through a load balancer to web servers supporting all three protocols. HTTP/2 and HTTP/3 introduce header compression via HPACK and QPACK respectively, reducing overhead. HTTP/3 replaces TCP with the QUIC transport layer, a UDP-based protocol that enables multiplexing and faster connection establishment. The diagram highlights how each component interacts and adapts to protocol changes, emphasizing the benefits of HTTP/2's multiplexing and header compression and HTTP/3's improved transport layer for latency and reliability.

Primary Focus

✓

Practice

(1/5)
1. For ensuring exactly-once payment event processing in a distributed payment gateway, which architecture is more appropriate given the constraint that external payment processors may send duplicate callbacks?
medium
A. Use an event sourcing pattern with idempotent event handlers and a unique event ID store
B. Use a relational database with unique constraints on callback IDs and synchronous processing
C. Use a stateless microservice that processes each callback independently without deduplication
D. Use a batch job that aggregates callbacks and processes them periodically

Solution

  1. Step 1: Identify the need for deduplication and exactly-once semantics

    Duplicate callbacks require idempotent processing and event tracking to avoid double charges.

  2. Step 2: Evaluate event sourcing with idempotent handlers

    Event sourcing stores all events immutably with unique IDs, enabling replay and deduplication.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Event sourcing with idempotent handlers ensures exactly-once processing [check]
Hint: Event sourcing + idempotent handlers handle duplicates best [check]
Common Mistakes:
2. If the Kafka cluster responsible for photo upload event streaming goes down, what exactly breaks in the system?
medium
A. Photo uploads fail immediately with HTTP 500 errors to users
B. Feed generation continues normally but stories fail to update
C. Photo metadata extraction and thumbnail generation stop; uploads succeed but processing is delayed indefinitely
D. User notifications about new photos are lost but photos appear in feed

Solution

  1. Step 1: Understand Kafka's role in event streaming

    Kafka streams photo upload events to downstream processors like metadata extraction and feed generation.

  2. Step 2: Trace failure impact

    If Kafka is down, photo uploads still succeed because upload service writes to storage directly. Feed generation depends on Kafka events for stories update; without Kafka, stories updates stop, but feed generation for photos continues from DB. Metadata extraction is delayed but not necessarily indefinite. Notifications are handled separately.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka outage stops stories update but feed photo generation continues [check]
Hint: Kafka outage blocks stories update, feed photos still served [check]
Common Mistakes:
3. You must choose between a monolithic architecture and microservices for a system with rapidly evolving features and a small team. Which choice best justifies your design decision to the interviewer?
medium
A. Choose microservices because they always scale better regardless of team size
B. Choose monolith to reduce operational complexity and speed up feature delivery for a small team
C. Choose microservices to isolate failures even if it increases deployment overhead
D. Choose monolith because it requires no testing or CI/CD pipelines

Solution

  1. Step 1: Analyze team size and feature velocity constraints

    Small teams benefit from simpler architectures to reduce overhead and speed delivery.

  2. Step 2: Evaluate operational complexity of microservices

    Microservices add deployment and operational complexity, which can slow small teams.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Monolith reduces complexity, speeds delivery for small teams [check]
Hint: Small teams prefer monoliths for simplicity and speed [check]
Common Mistakes:
4. You must choose between using a HyperLogLog or a Redis Set to count unique users in a high-traffic system with 100 million daily users. Which choice is best and why?
medium
A. Use Redis Set because it provides exact counts and is memory efficient at this scale
B. Use HyperLogLog because it guarantees zero false positives in membership queries
C. Use Redis Set because it supports fast union operations for merging counts
D. Use HyperLogLog because it uses fixed small memory with acceptable error for large cardinalities

Solution

  1. Step 1: Compare memory usage and accuracy

    Redis Sets store all unique IDs exactly, which is memory prohibitive at 100 million users; HyperLogLog uses fixed small memory with ~2% error.

  2. Step 2: Evaluate operational needs

    HyperLogLog supports efficient merges and approximate counts, suitable for large scale; Redis Sets are exact but scale poorly in memory.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    HyperLogLog trades accuracy for fixed small memory at scale [check]
Hint: Fixed small memory + approximate count -> HyperLogLog wins [check]
Common Mistakes:
5. At 10x scale, which component is most likely to become the bottleneck first when using a centralized auto-increment ID generator for a global service, and why?
hard
A. The database storing generated IDs, because it cannot handle the increased write volume
B. The network bandwidth between clients and the ID generator, due to increased latency
C. The centralized ID generator itself, because it is a single point of serialization and cannot scale horizontally
D. The client applications, because they cannot process IDs fast enough

Solution

  1. Step 1: Identify centralized ID generator role

    It serializes ID generation requests to maintain uniqueness and ordering.

  2. Step 2: Analyze scaling impact

    At 10x scale, the single generator becomes a serialization bottleneck that cannot be sharded or scaled horizontally, limiting throughput.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Centralized generator serialization -> first bottleneck at scale [check]
Hint: Single ID generator serializes -> bottleneck at scale [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