Bird
Raised Fist0

Global Server Load Balancing - Routing Traffic Across Data Centers

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

Receives DNS query from client

Client requests IP for service domain

Protocol:DNS (UDP)
BeforeClient has service domain name but no IP address
AfterDNS Resolver received query and is resolving IP
Global Load Balancer (Traffic Router)

Receives DNS query from resolver

Determines best data center IP based on config and health

Protocol:DNS (UDP)
BeforeLoad Balancer has no routing decision for this query
AfterLoad Balancer selects data center IP and returns it to resolver
Capacity & Configuration Database

Provides capacity and routing config to Load Balancer

Load Balancer queries DB for capacity and config data

Protocol:SQL
BeforeDB holds latest capacity and config data
AfterLoad Balancer caches config data for routing decisions
Health & Metrics Service

Sends health status updates to Load Balancer

Reports data center health metrics for routing

Protocol:gRPC
BeforeHealth Service continuously monitors data centers
AfterLoad Balancer updates routing based on health info
Data Center App Servers

Receives routed client traffic

Handles client requests routed by Load Balancer

Protocol:HTTP
BeforeApplication servers await incoming client traffic
AfterServers process client requests and respond
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│ Global DNS Resolver   │
└────────────┬──────────┘
             │ DNS Query (UDP)
             ▼
┌───────────────────────────────┐
│ Global Load Balancer           │
│ (Traffic Router)               │
└────────────┬──────────────────┘
             │ Config Lookup (SQL)
             ▼
┌───────────────────────────────┐
│ Capacity & Configuration DB    │
└────────────┬──────────────────┘
             │ Health Data (gRPC)
             ▼
┌───────────────────────────────┐
│ Health & Metrics Service       │
└────────────┬──────────────────┘
             │ Route Traffic (HTTP)
             ▼
┌───────────────────────────────┐
│ Data Center App Servers        │
└───────────────────────────────┘
Design Rationale

This Global Server Load Balancing system routes client DNS queries to the optimal data center. The Global DNS Resolver receives the client query and forwards it to the Global Load Balancer, which uses capacity and health data from the Configuration Database and Health & Metrics Service to select the best data center IP. The Load Balancer returns this IP to the resolver, which responds to the client. Subsequently, client traffic is routed to the chosen Data Center Application Servers. This architecture ensures traffic is directed based on real-time health and capacity, improving availability and performance globally.

Primary Focus

✓

Practice

(1/5)
1. A location-based service must efficiently index millions of businesses worldwide to support fast nearby searches within a 5km radius. Which component is best suited to handle spatial indexing for this use case?
easy
A. Use a relational database with latitude and longitude columns and perform range queries with indexes
B. Use a Geohash-based spatial index to bucket locations into hierarchical grids
C. Use a simple key-value store with business IDs as keys and coordinates as values
D. Use a full-text search engine like Elasticsearch without spatial extensions

Solution

  1. Step 1: Identify spatial indexing needs

    Relational DBs with lat/lon indexes (Use a relational database with latitude and longitude columns and perform range queries with indexes) do not scale well for large radius queries and millions of points due to expensive range scans.

  2. Step 2: Evaluate Geohash suitability

    Geohash (Use a Geohash-based spatial index to bucket locations into hierarchical grids) encodes locations into hierarchical grids enabling efficient prefix queries for nearby searches, making it ideal for large-scale spatial indexing.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Geohash buckets locations into grids for fast proximity queries [check]
Hint: Geohash buckets locations hierarchically for fast spatial queries [OK]
Common Mistakes:
2. For a social feed system with millions of users, which fan-out strategy is better when most users have a small number of followers but a few have millions, and why?
medium
A. Hybrid approach: fan-out on write for low-follower users, fan-out on read for high-follower users
B. Fan-out on read to reduce write amplification for all users
C. Fan-out on write for all users to guarantee low read latency
D. Fan-out on read for all users to minimize storage costs

Solution

  1. Step 1: Analyze follower distribution impact on fan-out

    Fan-out on write for users with millions of followers causes huge write amplification and storage overhead. Fan-out on read for low-follower users increases read latency unnecessarily.

  2. Step 2: Evaluate hybrid approach benefits

    Hybrid approach balances write amplification and read latency by applying fan-out on write only where follower count is manageable, and fan-out on read for heavy hitters.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Hybrid fan-out balances write cost and read latency [check]
Hint: Hybrid fan-out optimizes write/read trade-offs by follower count [check]
Common Mistakes:
3. Without a heartbeat mechanism in client-side service discovery, what exact failure occurs when a service instance crashes?
medium
A. The service registry automatically removes the crashed instance preventing stale routing
B. Clients continue sending requests to the crashed instance until cache expires, causing request failures
C. Clients immediately detect failure and reroute requests to healthy instances
D. Clients switch to server-side discovery to avoid stale instance usage

Solution

  1. Step 1: Understand heartbeat role in client-side discovery

    Heartbeats keep registry updated; without them, registry cannot detect crashed instances.

  2. Step 2: Trace failure impact

    Without heartbeats, registry retains stale instances; clients cache stale data and send requests to dead instances causing failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Registry removes crashed instances only if heartbeats present [check]
Hint: No heartbeat -> registry unaware -> stale instances persist [check]
Common Mistakes:
4. At 10x scale, which component in a consistent hashing database sharding system is most likely to fail first and why?
hard
A. The central shard metadata service, due to increased coordination overhead
B. The individual database shards, because storage capacity limits are reached first
C. The hash ring management service, because updating and propagating ring changes becomes a bottleneck
D. The client-side routing cache, as it cannot handle the increased number of shards efficiently

Solution

  1. Step 1: Identify scaling bottlenecks

    Central metadata service (The central shard metadata service, due to increased coordination overhead) may be distributed or avoided; shards (The individual database shards, because storage capacity limits are reached first) scale horizontally; client caches (The client-side routing cache, as it cannot handle the increased number of shards efficiently) can be sharded or refreshed incrementally.

  2. Step 2: Analyze hash ring management at scale

    Hash ring management (The hash ring management service, because updating and propagating ring changes becomes a bottleneck) requires updating and propagating ring changes to all nodes; at 10x scale, this coordination overhead and update frequency cause it to become the first bottleneck.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Hash ring updates bottleneck first at large scale [check]
Hint: Hash ring updates bottleneck first at large scale [OK]
Common Mistakes:
5. At 10x scale, which component in a consistent hashing system with virtual nodes is most likely to fail first and why?
hard
A. The physical nodes, because they cannot handle increased key storage and request load
B. The token metadata service, due to increased complexity managing many virtual nodes and frequent updates
C. The network, because consistent hashing increases network chatter exponentially with scale
D. The client-side hash function, as hashing large key sets becomes computationally infeasible

Solution

  1. Step 1: Identify scaling bottlenecks

    Physical nodes scale horizontally; network and hash function scale well with optimizations.

  2. Step 2: Analyze token metadata service

    Managing many virtual nodes and frequent node changes increases metadata complexity and update frequency, causing bottlenecks.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Token metadata service complexity grows fastest, causing first failure [check]
Hint: Token metadata complexity grows fastest 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