Bird
Raised Fist0

Load Balancing Algorithms - Round Robin, Least Connections, IP Hash, Weighted

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Load Balancer Layer

Receives client request and selects backend server

Uses configured algorithm (e.g., Round Robin) to pick a server

Protocol:HTTP
BeforeRequest just arrived at Load Balancer, no server selected
AfterBackend server selected based on algorithm and ready to receive request
Health Check Service

Checks health status of selected backend server

Returns server health to Load Balancer to confirm availability

Protocol:gRPC
BeforeLoad Balancer has selected a backend server but health unknown
AfterLoad Balancer confirmed server is healthy and can route request
Backend Server Pool

Processes client request

Handles request and generates response

Protocol:HTTP
BeforeBackend server is idle or processing other requests
AfterBackend server processed request and prepared response
Metrics & Monitoring

Records request handling metrics

Updates counters for requests served and latency

Protocol:REST API
BeforeMetrics reflect previous request counts and latencies
AfterMetrics updated with new request data from backend server
Configuration Store

Provides load balancing algorithm parameters

Supplies weights and algorithm type to Load Balancer

Protocol:Redis GET
BeforeLoad Balancer uses default or cached algorithm config
AfterLoad Balancer refreshed algorithm config for next requests
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Load Balancer Layer  │
└─────────────┬─────────┘
              │ HTTP Request
              ▼
┌───────────────────────┐
│  Health Check Service  │
└─────────────┬─────────┘
              │ Health Status Query
              ▼
┌───────────────────────┐
│   Backend Server Pool  │
└─────────────┬─────────┘
              │ Server Response
              ▼
┌───────────────────────┐
│  Metrics & Monitoring  │
└─────────────┬─────────┘
              │ Metrics Update
              ▼
┌───────────────────────┐
│  Configuration Store   │
└───────────────────────┘
Design Rationale

The Load Balancer Layer receives incoming client requests and selects a backend server using the configured load balancing algorithm such as Round Robin, Least Connections, IP Hash, or Weighted. Before routing the request, it consults the Health Check Service to verify the selected server's health status, ensuring requests are only sent to healthy servers. The Backend Server Pool processes the request and generates a response. Meanwhile, Metrics & Monitoring collects performance data like request counts and latency to track system health. The Configuration Store holds algorithm parameters and weights, which the Load Balancer fetches to adapt its routing decisions dynamically. This architecture ensures efficient, reliable request distribution with real-time health awareness and monitoring.

Primary Focus

✓

Practice

(1/5)
1. A web service needs to monitor its API latency to detect performance degradation. Which metric should it use to capture the experience of the slowest 1% of requests?
easy
A. P99 latency measurement
B. Average latency over all requests
C. Median (P50) latency
D. Maximum latency observed

Solution

  1. Step 1: Understand latency percentiles

    P99 latency captures the latency below which 99% of requests complete, highlighting the slowest 1% tail.

  2. Step 2: Why average and median fail

    Average latency can be skewed by outliers but doesn't reflect tail latency; median (P50) only shows the middle, missing slow requests; maximum latency is noisy and not stable.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    P99 latency highlights slowest 1% requests, not average or median [OK]
Hint: P99 shows slowest 1%, average hides tail latency [OK]
Common Mistakes:
2. In a consistent hashing ring, at Step 4 the request router receives a key and hashes it to a point on the ring. What happens next?
easy
A. The router assigns the key to the first node clockwise from the key's hash point
B. The router assigns the key to the node with the closest lower hash value
C. The router rehashes the key until it finds a node with available capacity
D. The router broadcasts the key to all nodes and waits for a response

Solution

  1. Step 1: Trace key assignment in consistent hashing

    Consistent hashing assigns keys to the first node clockwise from the key's hash on the ring.

  2. Step 2: Eliminate incorrect options

    Lower hash value assignment breaks ring semantics; rehashing or broadcasting is inefficient and not part of consistent hashing.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Consistent hashing assigns keys clockwise on the ring [check]
Hint: Keys go clockwise to next node on ring [check]
Common Mistakes:
3. In a sharded CRDT counter system, what exactly breaks if the shard state replication mechanism fails silently for several minutes?
medium
A. Local shard increments continue, but the global aggregated count lags behind until replication resumes
B. All increments are lost because shards cannot merge without replication
C. The global counter value becomes permanently inconsistent and cannot be recovered
D. The system blocks all increments until replication is restored to maintain consistency

Solution

  1. Step 1: Understand replication role in CRDT counters

    Replication propagates shard states to other replicas for merging. Without it, shards cannot merge and increments are isolated.

  2. Step 2: Trace failure impact

    Without replication, increments on isolated shards are effectively lost from global view until replication resumes; no blocking occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Replication failure isolates shards, causing lost increments globally [check]
Hint: No replication -> isolated shards -> lost global increments [check]
Common Mistakes:
4. For a hotel booking system requiring low-latency availability checks and strong double booking prevention, which architecture is best suited?
medium
A. Use a single relational database with serializable transactions for all reservations
B. Use a distributed cache with optimistic locking combined with a distributed lock service
C. Use an eventually consistent NoSQL database with background reconciliation jobs
D. Use client-side caching with periodic synchronization to the central database

Solution

  1. Step 1: Analyze latency and consistency requirements

    Low-latency availability checks require fast reads; strong double booking prevention requires coordination.

  2. Step 2: Evaluate architectures

    Single relational DB (Use a single relational database with serializable transactions for all reservations) provides strong consistency but suffers from high latency and scalability issues. Eventually consistent NoSQL (Use an eventually consistent NoSQL database with background reconciliation jobs) allows double bookings due to stale reads. Client-side caching (Use client-side caching with periodic synchronization to the central database) risks stale data and race conditions. Distributed cache with optimistic locking plus distributed locks (Use a distributed cache with optimistic locking combined with a distributed lock service) balances low latency reads with strong concurrency control.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Distributed locks + cache enable fast, consistent availability checks [check]
Hint: Combine cache speed with distributed locks for consistency [check]
Common Mistakes:
5. At 10x scale, which observability component is most likely to fail first and why?
hard
A. Centralized logging storage, because write throughput and storage costs grow linearly and cause bottlenecks
B. Alerting system, because it cannot process all incoming alerts in real-time at high scale
C. Distributed tracing backend, because the volume of spans grows exponentially with request fan-out, overwhelming storage and query systems
D. Metrics aggregation system, because it cannot shard time-series data effectively across many nodes

Solution

  1. Step 1: Analyze scaling characteristics of observability components

    Tracing volume grows exponentially with request fan-out, causing storage and query bottlenecks.

  2. Step 2: Compare with other components

    Logging scales linearly; metrics systems shard well; alerting scales with metrics, so less likely first failure.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Tracing volume explosion -> backend overwhelmed first [check]
Hint: Tracing volume explodes with fan-out, stressing backend first [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