Bird
Raised Fist0

Layer 4 vs Layer 7 Load Balancing - Transport vs Application Level

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
DNS Resolver

Resolves domain name to IP address

DNS Resolver sends UDP query to authoritative DNS and receives IP of Layer 4 LB

Protocol:DNS (UDP)
BeforeClient has domain name but no IP address
AfterClient obtains IP address of Layer 4 Load Balancer
Layer 4 Load Balancer (e.g., AWS NLB, HAProxy in TCP mode)

Accepts TCP connection and forwards to Layer 7 LB

Layer 4 LB uses transport info (IP, port) to select Layer 7 LB instance

Protocol:TCP (Layer 4)
BeforeTCP connection request arrives at Layer 4 LB
AfterTCP connection forwarded to Layer 7 Load Balancer
Layer 7 Load Balancer (e.g., NGINX, Envoy)

Processes HTTP request and routes to healthy backend

Layer 7 LB inspects HTTP headers and routes request based on URL/path

Protocol:HTTP/HTTPS (Layer 7)
BeforeHTTP request arrives at Layer 7 LB
AfterHTTP request forwarded to selected healthy backend server
Backend Application Servers

Processes request and generates response

Backend server executes application logic and prepares HTTP response

Protocol:HTTP/HTTPS
BeforeBackend server receives HTTP request
AfterBackend server sends HTTP response back to Layer 7 LB
Health Check Service

Periodically checks backend server health

Sends HTTP health check requests to backend servers to verify availability

Protocol:HTTP
BeforeBackend server health status unknown or stale
AfterHealth Check Service updates backend health status for load balancers
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ DNS Resolver  │
└───────┬───────┘
        │ DNS Query (UDP)
        ▼
┌───────────────────────────────────────┐
│ Layer 4 Load Balancer                  │
│ (AWS NLB, HAProxy TCP mode)            │
└───────┬───────────────────────────────┘
        │ TCP (Layer 4)
        ▼
┌───────────────────────────────────────┐
│ Layer 7 Load Balancer                  │
│ (NGINX, Envoy)                        │
└───────┬───────────────────────────────┘
        │ HTTP/HTTPS (Layer 7)
        ▼
┌───────────────────────────┐
│ Backend Application       │
│ Servers                   │
└───────┬───────────────────┘
        │ Health Check (HTTP)
        ▼
┌───────────────────────────┐
│ Health Check Service      │
└───────────────────────────┘
Design Rationale

This architecture illustrates the difference between Layer 4 and Layer 7 load balancing. The DNS Resolver translates domain names to IPs, directing clients to the Layer 4 Load Balancer, which operates at the transport layer forwarding TCP connections without inspecting HTTP content. The Layer 7 Load Balancer then performs application-level routing by inspecting HTTP headers and paths, enabling advanced routing decisions like path-based or header-based routing. Backend Application Servers handle the actual request processing. The Health Check Service continuously monitors backend health, informing load balancers to avoid unhealthy servers. This layered approach balances efficiency and flexibility, with Layer 4 providing fast transport routing and Layer 7 enabling rich application-aware routing.

Primary Focus

✓

Practice

(1/5)
1. A distributed key-value store must guarantee that once a client writes a value, any subsequent read by the same client returns that value or a newer one, even if the client switches servers. Which consistency model best supports this requirement?
easy
A. Read-your-writes consistency, because it guarantees the client sees its own writes regardless of server
B. Causal consistency, because it orders all operations globally
C. Eventual consistency, because the system will converge to the latest value eventually
D. Strong consistency, because it ensures all clients see the latest write immediately

Solution

  1. Step 1: Understand client-centric guarantees

    Read-your-writes consistency ensures that a client always sees its own writes, even if it switches servers, without requiring global synchronization.

  2. Step 2: Eliminate other models

    Strong consistency enforces global order but is costly and not required here; eventual consistency does not guarantee immediate visibility of own writes; causal consistency orders related operations but does not guarantee read-your-writes for a single client.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Read-your-writes consistency ensures client sees own writes immediately [check]
Hint: Read-your-writes means client always sees own writes [check]
Common Mistakes:
2. In the analytics pipeline, at step 4 the Flink job reads from Kafka and applies windowed aggregations. What is the state of the Flink job's checkpoint when a failure occurs immediately after step 4?
easy
A. The checkpoint includes all processed events up to the failure, ensuring exactly-once semantics
B. The checkpoint is incomplete, so Flink will reprocess some events causing duplicates
C. The checkpoint is empty because Flink does not checkpoint at this step
D. The checkpoint only contains metadata, not the actual aggregation state

Solution

  1. Step 1: Understand Flink's checkpointing mechanism

    Flink performs distributed snapshots capturing the full operator state including windowed aggregations at step 4.

  2. Step 2: Reason about failure impact

    Since checkpoint includes all processed events and state, Flink can restore exactly-once semantics after failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Flink checkpoints capture full operator state for exactly-once recovery [check]
Hint: Flink checkpoints save full operator state atomically [check]
Common Mistakes:
3. In the video transcoding pipeline, at step 4 the Transcoding Worker checks the job queue for new tasks. What happens if the queue is empty at this step?
easy
A. The Transcoding Worker immediately shuts down to save resources
B. The Transcoding Worker fetches tasks from a backup queue stored in the database
C. The Transcoding Worker polls the queue repeatedly with a short delay until new tasks arrive
D. The Transcoding Worker blocks waiting on a message broker notification until a new task is available

Solution

  1. Step 1: Understand Transcoding Worker queue interaction

    Transcoding Workers typically use message brokers with blocking or long-polling to avoid busy-waiting. Immediate shutdown (A) wastes throughput. Polling with delay (B) causes unnecessary load and latency. Backup queue in DB (D) is inefficient and not standard.

  2. Step 2: Recognize blocking on broker notification

    Blocking on a message broker notification (e.g., Kafka consumer poll or RabbitMQ consumer wait) is efficient and standard to wait for new tasks.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Blocking on broker notification avoids busy polling [check]
Hint: Workers block on broker notification, not busy poll [check]
Common Mistakes:
4. At 10x scale, which component of a distributed Count-Min Sketch system is most likely to fail first and why?
hard
A. The network bandwidth saturates due to large sketch state synchronization
B. The sketch arrays in memory overflow due to fixed size limits
C. The hash functions become slower, increasing latency linearly
D. The centralized coordinator bottlenecks due to serializing all update requests

Solution

  1. Step 1: Identify bottleneck in distributed updates

    Centralized coordinator serializes updates to maintain consistency, limiting throughput.

  2. Step 2: Analyze other components

    Network bandwidth and hash function speed scale better; sketch arrays have fixed size but don't overflow.

  3. Step 3: Understand scale impact

    At 10x scale, coordinator becomes overwhelmed, causing update latency and failures.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Central coordinator serialization bottlenecks updates at scale [check]
Hint: Central coordinator serializes updates, bottlenecking at scale [check]
Common Mistakes:
5. At 10x scale, which component in WhatsApp's architecture is most likely to fail first and why?
hard
A. Chat Servers because WebSocket connections are stateful and cannot be resharded easily
B. Kafka brokers because partition count cannot be increased dynamically
C. The database because it cannot handle 10x more writes without sharding
D. Presence service because TTL cache invalidations become too frequent

Solution

  1. Step 1: Analyze stateful WebSocket connections on Chat Servers

    Chat Servers maintain in-memory state per WebSocket; scaling requires connection migration which is complex.

  2. Step 2: Compare other components

    Databases can shard; Kafka partitions can be increased with rebalancing; presence TTL cache scales horizontally.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful WebSocket connections -> Chat Servers bottleneck at scale [check]
Hint: Stateful WebSocket -> Chat Servers bottleneck at 10x 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