Bird
Raised Fist0

DNS Load Balancing and GeoDNS for Global Traffic Distribution

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
DNS Client

Sends DNS query

Client sends DNS query to resolve service domain

Protocol:UDP DNS Query
BeforeClient needs IP for service domain
AfterDNS query is in transit to DNS Edge Resolver
DNS Edge Resolver

Receives DNS query and performs GeoIP lookup

Uses GeoIP Database to determine client location

Protocol:Local Cache / DB Query
BeforeDNS query received, no location info yet
AfterClient IP mapped to geographic region
GeoIP Database

Returns geographic location for client IP

Provides region data to DNS Edge Resolver

Protocol:DB Query
BeforeGeoIP DB has client IP data
AfterGeoIP DB returns location info
GeoDNS Control Plane

Determines best data center based on geo and health

Uses health status and config to select endpoint

Protocol:Internal API Call
BeforeGeoIP location known, health data available
AfterOptimal data center IP selected for response
Health Check & Metrics Aggregator

Provides latest health status of data centers

Aggregates health checks and metrics for GeoDNS

Protocol:Health Status Update
BeforeHealth data may be stale
AfterGeoDNS Control Plane has fresh health info
Config API Service

Updates GeoDNS and health check configurations

Applies new routing policies and health check params

Protocol:REST API
BeforeOld config in place
AfterNew config applied for GeoDNS and health checks
DNS Edge Resolver

Responds to client with selected data center IP

Sends DNS response with optimal endpoint

Protocol:UDP DNS Response
BeforeOptimal endpoint selected
AfterClient receives DNS response with IP
🏗️
Architecture Diagram
Architecture Diagram
┌─────────────┐
│ DNS Client  │
└──────┬──────┘
       │ UDP DNS Query
       ▼
┌───────────────────┐
│ DNS Edge Resolver │
└────────┬──────────┘
         │ GeoIP Lookup (local cache)
         ▼
┌────────────────┐
│ GeoIP Database │
└────────┬───────┘
         │ GeoIP Data
         ▼
┌───────────────────────┐
│ GeoDNS Control Plane  │
└────────┬──────────────┘
         │ Health & Config Data
         ▼
┌───────────────────────────────┐
│ Health Check & Metrics Aggregator │
└────────┬──────────────────────┘
         │ Health Status Updates
         ▼
┌───────────────────────┐
│ Config API Service    │
└───────────────────────┘
Design Rationale

This architecture shows how a DNS query from a client is resolved using GeoDNS and health data to direct traffic globally. The DNS Edge Resolver receives the query and uses the GeoIP Database to determine the client's location. The GeoDNS Control Plane then selects the best data center based on geographic proximity and health status, which is continuously updated by the Health Check & Metrics Aggregator. Configuration changes are managed by the Config API Service, ensuring routing policies and health checks stay current. This design balances global traffic efficiently by combining geographic data with real-time health metrics, improving latency and availability.

Primary Focus

✓

Practice

(1/5)
1. A notification system must handle 1 million notification writes per second and fan out to millions of devices asynchronously. Which component best decouples the write load from delivery workers to ensure durability and scalability?
easy
A. Use a simple HTTP REST API to synchronously send notifications to all devices
B. Use a relational database with sharded tables to store notifications and poll for delivery
C. Use an in-memory cache like Redis to store notifications and push directly to devices
D. Use a distributed message queue like Kafka partitioned by user ID for ordered, durable fan-out

Solution

  1. Step 1: Identify the role of the message queue

    Kafka provides durable, partitioned logs that decouple producers from consumers, enabling high write throughput and ordered delivery per user.

  2. Step 2: Evaluate other options

    Relational DB polling (A) can't handle 1M writes/sec efficiently; Redis (C) lacks durability and persistence guarantees; synchronous HTTP (D) blocks on delivery and doesn't scale.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka partitions by user ID -> durable, ordered fan-out [check]
Hint: Kafka partitions decouple writes from delivery at scale [check]
Common Mistakes:
2. In a system where a client writes a user profile update to DynamoDB, then a cache invalidation message is sent to Redis at step 4, what happens if the cache invalidation fails at step 4?
easy
A. DynamoDB write is rolled back automatically to maintain consistency
B. Redis automatically retries invalidation and blocks client until success
C. The cache remains stale until TTL expires or manual refresh
D. Client receives an error and retries the entire update operation

Solution

  1. Step 1: Trace cache invalidation at step 4

    Cache invalidation is asynchronous and best-effort; failure does not rollback DB writes.

  2. Step 2: Understand failure impact on cache state

    If invalidation fails, Redis cache remains stale until TTL expiry or next explicit refresh.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Failed cache invalidation -> stale cache until TTL or manual refresh [check]
Hint: Failed cache invalidation -> stale cache, DB write persists [check]
Common Mistakes:
3. A messaging system must handle 1 million writes per second and guarantee message durability despite server crashes. Which component best ensures durability without blocking producers?
easy
A. In-memory queue with periodic disk snapshots
B. Distributed log like Apache Kafka with partitioned topics
C. Simple Redis list with persistence disabled
D. Direct synchronous writes to a relational database

Solution

  1. Step 1: Identify durability and high write throughput needs

    In-memory queues with snapshots (A) risk data loss on crash; Redis without persistence (C) loses data on restart; synchronous DB writes (D) block producers and limit throughput.

  2. Step 2: Evaluate Kafka's distributed log

    Kafka partitions topics for parallelism and persists data durably on disk, allowing high throughput and crash recovery without blocking producers.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka partitions + durable log -> high throughput + durability [check]
Hint: Durable logs handle high writes without blocking producers [OK]
Common Mistakes:
4. Without the bulkhead pattern implemented, what exactly happens when one microservice's database connection pool saturates under load?
medium
A. The entire system queues requests indefinitely, causing high latency everywhere
B. Requests to the saturated service block and cause thread starvation, cascading failures to other services
C. The service automatically rejects requests, preventing impact on other services
D. Load balancers detect saturation and reroute traffic to healthy instances instantly

Solution

  1. Step 1: Understand absence of bulkhead isolation

    Without bulkheads, saturation causes blocking (B) and thread starvation, but automatic rejection (C) is a bulkhead feature. Queuing indefinitely (A) is unlikely without bulkheads. Load balancers (D) don't detect internal resource saturation.

  2. Step 2: Trace failure impact

    Without bulkheads, blocking threads cause cascading failures; with bulkheads, requests are rejected to contain blast radius.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Without bulkheads, blocking causes cascading failures [check]
Hint: No bulkheads -> blocking threads cascade failures [check]
Common Mistakes:
5. At 10x scale increase for a system using Redis as a cache in front of DynamoDB, which component is most likely to fail first and why?
hard
A. Redis cache servers because memory pressure causes eviction storms and latency spikes
B. Application servers because CPU saturates handling cache misses
C. Network load balancers because they cannot handle increased connection counts
D. DynamoDB because partition throughput limits are exceeded causing throttling

Solution

  1. Step 1: Analyze Redis cache behavior under 10x load

    Increased load causes Redis memory pressure, triggering eviction storms and latency spikes.

  2. Step 2: Compare Redis failure risk to DynamoDB and other components

    DynamoDB scales well with partitioning; network and app servers scale horizontally; Redis memory is stateful and harder to scale quickly.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Redis memory pressure -> eviction storms -> latency spikes first at scale [check]
Hint: Redis memory pressure -> eviction storms cause first failure 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