Global server load balancing (GSLB) in HLD - System Design Exercise

Design: Global Server Load Balancing (GSLB) System

Design focuses on DNS-based global load balancing and health monitoring of data centers. Does not cover internal data center load balancing or application logic.

Functional Requirements

FR1: Distribute user requests across multiple geographically distributed data centers

FR2: Automatically route users to the closest or best-performing data center

FR3: Provide failover in case a data center becomes unavailable

FR4: Support DNS-based load balancing with low latency

FR5: Handle at least 1 million concurrent users globally

FR6: Ensure p99 DNS resolution latency under 100ms

FR7: Provide 99.9% availability for routing service

Non-Functional Requirements

NFR1: Must work across multiple regions and continents

NFR2: DNS TTL should be configurable but typically low (e.g., 30 seconds)

NFR3: System must handle sudden traffic spikes gracefully

NFR4: Data centers may have different capacities and health status

NFR5: Latency and network conditions vary by user location

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Global DNS servers with authoritative zones

Health check service for data centers

Traffic routing logic (geo-IP, latency measurement)

Configuration management for data center metadata

Monitoring and alerting system

Cache and TTL management

Design Patterns

DNS-based load balancing

Health check and failover pattern

Geo-location routing

Weighted round-robin or latency-based routing

Caching and TTL optimization

Reference Architecture

          +---------------------+
          |   User DNS Resolver  |
          +----------+----------+
                     |
                     | DNS Query
                     v
          +---------------------+       +---------------------+
          | Global DNS Servers   |<----->| Health Check Service |
          | (Authoritative DNS)  |       +---------------------+
          +----------+----------+
                     |
          +----------+----------+----------+
          |          |          |          |
          v          v          v          v
    Data Center  Data Center  Data Center  Data Center
    (Region A)  (Region B)  (Region C)  (Region D)

Components

Global DNS Servers

Authoritative DNS servers (e.g., Bind, NSD, or cloud DNS)

Respond to DNS queries with IP addresses of the best data center based on routing logic

Health Check Service

Custom service or monitoring tools (e.g., Prometheus, Nagios)

Continuously monitor health and availability of each data center

Routing Logic Module

Custom software or DNS policy engine

Decide which data center IP to return based on geo-location, latency, health, and capacity

Configuration Management

Database or config files

Store metadata about data centers, weights, and routing policies

Monitoring and Alerting

Monitoring tools (e.g., Grafana, PagerDuty)

Track system health, DNS latency, and alert on failures

Request Flow

1. User's device sends DNS query to local DNS resolver.

2. Local DNS resolver forwards query to Global DNS Servers authoritative for the domain.

3. Global DNS Servers invoke Routing Logic Module to select the best data center IP.

4. Routing Logic uses geo-IP lookup, health status, and latency data to pick data center.

5. Global DNS Servers respond with IP address of selected data center.

6. User connects to the selected data center's IP for service.

7. Health Check Service continuously probes data centers and updates their health status.

8. Routing Logic updates decisions based on health and capacity changes.

9. Monitoring system tracks DNS response times and data center availability.

Database Schema

Entities: - DataCenter(id, name, region, ip_addresses, capacity, status) - HealthCheck(id, data_center_id, timestamp, status, latency) - RoutingPolicy(id, criteria_type, parameters, weight) Relationships: - Each DataCenter has many HealthCheck records - RoutingPolicy defines rules applied to DataCenters for selection

Scaling Discussion

Bottlenecks

Global DNS servers can become overwhelmed by high query volume

Health check service may lag in detecting failures at scale

Geo-IP lookups can add latency if not cached efficiently

DNS caching by clients and ISPs can delay failover

Routing logic complexity can increase latency in DNS responses

Solutions

Deploy multiple anycast DNS servers globally to distribute query load

Use distributed health check agents close to data centers for faster detection

Cache geo-IP results and use efficient lookup libraries

Set low DNS TTL values and use DNS features like DNS push updates if supported

Optimize routing logic with precomputed decisions and caching

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain how DNS-based routing works and why it's suitable for GSLB

Discuss health checks and failover mechanisms

Describe how geo-location and latency influence routing decisions

Mention DNS caching challenges and TTL trade-offs

Highlight scalability strategies like anycast DNS and distributed health checks

Practice

1. What is the primary purpose of Global Server Load Balancing (GSLB)?

easy

A. To balance load only within a single data center

B. To direct user requests to the best global server based on location and health

C. To encrypt data between servers globally

D. To store user data in a centralized database

Solution

1. Step 1: Understand GSLB's role in system design

   GSLB directs traffic globally to optimize speed and availability by choosing the best server.

2. Step 2: Differentiate GSLB from local load balancing

   Local load balancing manages traffic inside a data center, while GSLB manages traffic across data centers worldwide.

3. Final Answer:

   To direct user requests to the best global server based on location and health -> Option B

4. Quick Check:

   GSLB = directs users globally [OK]

Hint: GSLB chooses best global server, not just local load [OK]

Common Mistakes:

• Confusing GSLB with local load balancing
• Thinking GSLB handles data encryption
• Assuming GSLB stores user data centrally

2. Which of the following is a correct component used in GSLB architecture?

easy

A. Global DNS server with health checks

B. Single local load balancer without DNS

C. Centralized database for user sessions

D. Static IP routing without failover

Solution

1. Step 1: Identify key GSLB components

   GSLB uses global DNS servers that perform health checks to route users to healthy servers.

2. Step 2: Eliminate incorrect options

   Local load balancers alone don't handle global routing; centralized databases and static IP routing don't provide dynamic failover.

3. Final Answer:

   Global DNS server with health checks -> Option A

4. Quick Check:

   GSLB = global DNS + health checks [OK]

Hint: GSLB needs DNS with health checks, not just local balancers [OK]

Common Mistakes:

• Ignoring the role of DNS in GSLB
• Confusing local load balancer as GSLB
• Assuming static routing works for failover

3. Consider a GSLB setup with three data centers: US, Europe, and Asia. If the US data center is down, where will the DNS direct a user from Europe?

medium

A. To the closest healthy data center, Europe or Asia

B. To a random data center without health checks

C. To the US data center regardless of health

D. To the Asia data center only

Solution

1. Step 1: Understand GSLB health check impact

   If the US data center is down, GSLB excludes it from routing decisions.

2. Step 2: Determine routing for European user

   The DNS directs the user to the closest healthy data center, which could be Europe or Asia depending on proximity and health.

3. Final Answer:

   To the closest healthy data center, Europe or Asia -> Option A

4. Quick Check:

   GSLB routes to closest healthy server [OK]

Hint: GSLB skips unhealthy centers, picks closest healthy [OK]

Common Mistakes:

• Routing to down data center ignoring health
• Choosing random data center without checks
• Always routing to Asia regardless of location

4. A GSLB system is not redirecting traffic away from a failed data center. What is the most likely cause?

medium

A. User's browser cache is cleared

B. DNS TTL is set to zero

C. Load balancer inside data center is overloaded

D. Health checks are not configured or failing silently

Solution

1. Step 1: Analyze GSLB failure to redirect

   If traffic is not redirected from a failed data center, health checks likely are missing or not reporting failures.

2. Step 2: Evaluate other options

   DNS TTL zero causes frequent lookups but doesn't prevent failover; local load balancer overload or browser cache do not affect global DNS routing.

3. Final Answer:

   Health checks are not configured or failing silently -> Option D

4. Quick Check:

   Health checks missing = no failover [OK]

Hint: Check health checks first if failover fails [OK]

Common Mistakes:

• Blaming DNS TTL for failover issues
• Confusing local load balancer issues with GSLB
• Assuming browser cache affects server routing

5. You need to design a GSLB system for a global video streaming service. Which combination best improves user experience and reliability?

hard

A. Single global load balancer without DNS + static IP routing

B. Local load balancers only with no global routing

C. Global DNS with health checks + local load balancers + geo-proximity routing

D. DNS-based routing without health checks or load balancing

Solution

1. Step 1: Identify key GSLB features for video streaming

   Global DNS with health checks ensures users reach healthy servers; local load balancers distribute load inside data centers.

2. Step 2: Consider geo-proximity routing benefits

   Routing users to nearest data center reduces latency, improving streaming quality and reliability.

3. Step 3: Eliminate less effective options

   Single load balancer or no health checks cause bottlenecks or failover issues; local only misses global optimization.

4. Final Answer:

   Global DNS with health checks + local load balancers + geo-proximity routing -> Option C

5. Quick Check:

   Combine global DNS, health checks, local balancers, geo-routing [OK]

Hint: Combine global DNS, health checks, and geo-routing for best results [OK]

Common Mistakes:

• Ignoring health checks in DNS routing
• Using single load balancer for global traffic
• Skipping geo-proximity routing for latency