Bird
Raised Fist0

Why Load Balancers Exist and What Problems They Solve

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

Resolves domain name to IP of Global Load Balancer

Client sends DNS query; DNS Resolver returns IP of Global Load Balancer

Protocol:UDP DNS Query
BeforeClient only knows domain name, no IP address
AfterClient has IP address of Global Load Balancer to send requests
Global Load Balancer

Receives client request and routes to Regional Load Balancer

Global LB selects regional LB based on client location and health status

Protocol:TCP/HTTP(S)
BeforeGlobal LB has routing table with regional LB IPs and health info
AfterRequest forwarded to appropriate Regional Load Balancer
Regional Load Balancer

Distributes request to a healthy backend server

Regional LB uses health info to pick a backend server for load balancing

Protocol:TCP/HTTP(S)
BeforeRegional LB has list of backend servers with health status
AfterRequest forwarded to selected healthy backend server
Health Check Service

Periodically checks backend server health

Sends HTTP health check requests to backend servers and updates status

Protocol:HTTP Health Check
BeforeBackend server health status unknown or outdated
AfterUpdated health status used by Regional Load Balancer for routing
Backend Application Servers

Processes client request and generates response

Backend server executes application logic and returns response

Protocol:TCP/HTTP(S)
BeforeRequest received from Regional Load Balancer
AfterResponse generated and sent back through load balancers to client
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ DNS Resolver  │
└───────┬───────┘
        │ DNS Query (UDP)
        ▼
┌───────────────────────────────┐
│ Global LB (e.g., AWS Global)  │
│ Accelerator                   │
└───────────────┬───────────────┘
                │ TCP/HTTP(S)
                ▼
      ┌───────────────────────┐
      │ Regional LB (e.g.,    │
      │ NGINX, Envoy)         │
      └─────────────┬─────────┘
                    │ TCP/HTTP(S)
                    ▼
           ┌───────────────────────┐
           │ Health Check Service   │
           └─────────────┬─────────┘
                         │ Health Check (HTTP)
                         ▼
           ┌───────────────────────────┐
           │ Backend Application Servers│
           └───────────────────────────┘
Design Rationale

This architecture illustrates why load balancers exist: to distribute client requests efficiently and reliably across backend servers. The DNS Resolver directs clients to the Global Load Balancer, which routes requests geographically and based on health to Regional Load Balancers. Regional Load Balancers then distribute traffic only to healthy backend servers, as verified by the Health Check Service. This layered approach solves problems of scalability, fault tolerance, and latency by ensuring requests reach available servers closest to clients, preventing overload and downtime.

Primary Focus

✓

Practice

(1/5)
1. In a fraud detection system ingesting thousands of transactions per second, which component is best suited to decouple the high-throughput transaction ingestion from downstream real-time scoring to avoid backpressure?
easy
A. Use a relational database with batch inserts to buffer transactions
B. Use direct synchronous HTTP calls from ingestion to scoring service
C. Use an in-memory cache like Redis to store incoming transactions temporarily
D. Use a distributed message queue like Kafka with partitioning by user ID

Solution

  1. Step 1: Identify decoupling mechanism

    Relational DB batch inserts (A) add latency and don't handle high write throughput well. Redis (C) lacks durability guarantees for buffering. Direct synchronous calls (D) cause backpressure and tight coupling.

  2. Step 2: Evaluate Kafka suitability

    Kafka supports high-throughput, partitioned by user ID to maintain ordering per user, and durable storage, enabling asynchronous processing and backpressure handling.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka partitions decouple ingestion and scoring with durability and ordering [check]
Hint: Kafka partitions buffer high-throughput streams reliably [check]
Common Mistakes:
2. In the indexing pipeline, at step 3, the Indexer receives a batch of parsed documents. What state does the Indexer maintain immediately after processing this batch?
easy
A. The Indexer updates the inverted index with new terms but keeps the batch metadata for consistency checks
B. The Indexer sends the batch to the PageRank component before updating the index
C. The Indexer marks the batch as indexed and immediately deletes the raw documents
D. The Indexer queues the batch for re-parsing if term frequency thresholds are not met

Solution

  1. Step 1: Trace Indexer behavior at step 3

    The Indexer updates the inverted index with terms from the batch and retains batch metadata for consistency and fault tolerance.

  2. Step 2: Eliminate incorrect states

    Deleting raw documents immediately risks data loss. PageRank runs after indexing, not before. Re-parsing is triggered by errors, not term frequency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Indexer updates index and keeps metadata for consistency [check]
Hint: Indexer updates index, keeps metadata for consistency [check]
Common Mistakes:
3. In a horizontally scaled web service with a load balancer distributing requests to stateless app servers, at step 3 the load balancer receives a request from a client with a session cookie. What happens if the load balancer uses round-robin without sticky sessions?
easy
A. The client session cookie is ignored and a new session is created on each request
B. The request is always routed to the same app server that holds the session state
C. The load balancer caches the session state and forwards it to the app server
D. The request may be routed to a different app server, causing session state loss if servers are stateless

Solution

  1. Step 1: Understand load balancer behavior with round-robin and no sticky sessions

    Requests are distributed evenly but not consistently to the same server.

  2. Step 2: Analyze session state handling

    Stateless servers do not hold session state, so routing to different servers does not cause loss; but if state is stored in-memory, session loss occurs.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Round-robin without sticky sessions routes requests to different servers, risking session loss [check]
Hint: Round-robin without sticky sessions breaks session affinity [check]
Common Mistakes:
4. If the Dead Letter Queue component is removed from the system, what is the most likely failure scenario when a message processing fails repeatedly?
medium
A. The main queue blocks processing as failed messages are retried indefinitely, causing backpressure
B. The system switches to synchronous processing, increasing latency but ensuring delivery
C. Messages are automatically routed to a backup queue with no delay
D. Messages are silently dropped without any retry or alerting

Solution

  1. Step 1: Understand DLQ role in failure isolation

    Without DLQ, failed messages remain in the main queue causing retries that block subsequent messages.

  2. Step 2: Evaluate failure outcomes

    Silent drops (A) lose data; automatic routing (C) requires DLQ logic; synchronous fallback (D) is not automatic.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    No DLQ -> retries block main queue causing backpressure [check]
Hint: No DLQ means retries block main queue, causing backpressure [OK]
Common Mistakes:
5. For a payment API that must guarantee exactly-once processing despite client retries, which architecture best balances consistency and performance?
medium
A. Use a strongly consistent centralized idempotency key store with synchronous writes before processing
B. Use a distributed cache with eventual consistency for idempotency keys to maximize throughput
C. Rely on client-generated unique request IDs and process all requests without server-side deduplication
D. Use asynchronous background reconciliation to detect and fix duplicates after processing

Solution

  1. Step 1: Evaluate consistency needs

    Exactly-once processing requires strong consistency on idempotency keys to prevent duplicates during retries.

  2. Step 2: Compare architectures

    Distributed cache with eventual consistency risks duplicates; client-only IDs lack server enforcement; async reconciliation delays correctness.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Strongly consistent idempotency store ensures exactly-once processing [check]
Hint: Strong consistency needed for exactly-once idempotency [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