Bird
Raised Fist0

DNS Load Balancing and GeoDNS for Global Traffic Distribution

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
🏗️
DNS Load Balancing and GeoDNS for Global Traffic Distribution
Design a scalable, low-latency DNS-based global traffic distribution system with geo-awareness
mediumNetworking and ProtocolsFreq: medium
⚙️
Functional Requirements
  • Route user DNS queries to the nearest or optimal data center based on geo-location
  • Support weighted load balancing across multiple data centers for traffic distribution
  • Provide health checks and failover to avoid routing to unhealthy data centers
  • Allow dynamic updates of DNS records and geo-routing policies with minimal TTL impact
  • Support fallback routing when geo-location data is unavailable or ambiguous
  • Expose APIs for managing geoDNS configurations and monitoring traffic distribution
📊
Non-Functional Requirements
  • Handle 2 billion daily active users globally
  • Achieve 99.99% availability for DNS query responses
  • Ensure DNS query P99 latency under 100ms globally
  • Support peak DNS query QPS of approximately 925K queries per second
  • Provide DNS record update propagation within 60 seconds globally
❓
Clarifying Questions to Ask
  • What is the expected TTL for DNS records and how often do geo-routing policies change?
  • Are we supporting both IPv4 and IPv6 queries?
  • What is the granularity of geo-location data (country, region, city)?
  • Should the system support weighted load balancing or only simple nearest routing?
  • What health check mechanisms are required for data center availability?
  • Is integration with existing DNS providers or authoritative servers expected?
Out of Scope
✗ Designing the underlying application or service infrastructure behind data centers
✗ Implementing client-side DNS caching or resolver behavior
✗ Designing the IP routing or BGP-level traffic engineering
✗ Handling DNSSEC cryptographic key management
📌
Assumptions
  • 2 billion daily active users globally
  • Each user generates on average 40 DNS queries per day
  • Average DNS query size is 100 bytes
  • DNS query traffic is uniformly distributed over 24 hours with 3x peak factor
⚡
QPS Calculation
write qps2B users × 40 queries/user/day / 86400 seconds ≈ 925,926 writes/sec
peak write qps925,926 × 3 (peak factor) ≈ 2,777,778 writes/sec
read qpsAssuming 10x read amplification due to caching layers, read_qps ≈ 27.7M queries/sec
💾
Storage Estimate
daily storage2B × 40 × 100 bytes = 8 TB/day
retention days7
total storage8 TB × 7 = 56 TB
with replication56 TB × 3 (replication factor) = 168 TB total storage
🖥️
Server Estimate
dns edge serversTo handle 27.7M QPS reads with 10K QPS per server, need ~2,770 DNS edge servers globally
control plane serversFor geo-routing config management and health checks, estimate 50 servers for high availability and low latency
🏗️
Architecture Diagram
Architecture Diagram
          +----------------------+
          |   Global DNS Clients  |
          +----------+-----------+
                     | DNS Query
                     v
          +----------------------+
          |  DNS Edge Resolver   |
          | (Anycast + GeoIP DB) |
          +----------+-----------+
                     | GeoDNS Query
                     v
          +----------------------+
          | GeoDNS Control Plane |
          | (Policy + Health DB) |
          +----------+-----------+
                     | Health Checks +
                     | Config Updates
                     v
          +----------------------+
          | Data Center Health    |
          | & Metrics Aggregator  |
          +----------------------+
🧩
Components
DNS Edge Resolver
Authoritative DNS servers deployed globally with Anycast IPs to receive user DNS queries
Why thisAnycast routing ensures queries reach nearest DNS edge server, reducing latency and improving availability
Why notUnicast DNS servers require complex client-side geo-routing and increase latency due to centralized points
GeoIP Database
Local database at DNS edge servers mapping client IPs to geo-locations for routing decisions
Why thisMaxMind GeoIP2 provides accurate, regularly updated IP-to-location mapping with low lookup latency
Why notCustom IP geolocation services require heavy maintenance and have slower update cycles
GeoDNS Control Plane
Centralized service managing geo-routing policies, weighted load balancing, and health status of data centers
Why thisApache Cassandra stores geo-routing configs with high write throughput and multi-region replication for low latency
Why notRelational DBs like PostgreSQL do not scale linearly at 2.7M writes/sec and have complex sharding
Health Check & Metrics Aggregator
Continuously monitors data center health and performance metrics to update routing decisions dynamically
Why thisPrometheus collects metrics with alerting rules; integrates with control plane for real-time failover
Why notPolling via DNS queries alone is slow and unreliable for health detection at scale
Configuration API Service
RESTful API for operators to update geo-routing policies, weights, and TTLs dynamically
Why thisKong API Gateway with Kubernetes backend provides scalable, secure, and versioned config management
Why notManual config file updates or CLI tools do not support dynamic updates or audit trails
🔄
Data Flow
1
Global DNS Client → DNS Edge Resolver
Client sends DNS query to nearest Anycast IP
Anycast routes query to geographically closest DNS edge server
2
DNS Edge Resolver → GeoIP Database
Lookup client IP to determine geo-location
GeoIP DB provides city/region-level location for routing
3
DNS Edge Resolver → GeoDNS Control Plane
Query geo-routing policy and data center health status
Control plane returns best data center IP based on location and health
4
DNS Edge Resolver → Global DNS Client
Respond with DNS record pointing to selected data center IP
TTL set low (e.g., 60s) for fast failover and policy updates
5
Health Check & Metrics Aggregator → GeoDNS Control Plane
Push health status and performance metrics
Control plane updates routing policies dynamically based on health
6
Configuration API Service → GeoDNS Control Plane
Operators update geo-routing weights, policies, and TTLs via API
Changes propagate quickly to DNS edge resolvers for minimal impact

Practice

(1/5)
1. A distributed API rate limiter must enforce limits with minimal latency at the network edge. Which component is best suited to perform this enforcement?
easy
A. Centralized database that aggregates all request counts for global enforcement
B. Edge cache with local counters and periodic sync to central store
C. Batch job that processes logs every minute to update usage stats
D. Client-side SDK that tracks usage and blocks requests locally

Solution

  1. Step 1: Identify edge enforcement needs

    Enforcement must be low-latency and close to the client to avoid network round trips.
  2. Step 2: Evaluate options for latency and consistency

    Centralized DB (A) adds latency; batch jobs (C) are too delayed; client SDK (D) is untrustworthy. Edge cache with local counters (B) balances latency and eventual consistency.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Edge cache enforces limits locally with periodic sync [check]
Hint: Enforce limits close to client with local counters [check]
Common Mistakes:
2. In the Pastebin system request flow, at Step 4 the Expiration Worker scans stored snippets to remove expired entries. What state does the worker observe for a snippet whose TTL just expired but is still being accessed by a user?
easy
A. The snippet is immediately deleted and inaccessible to the user
B. The snippet remains accessible until the worker completes the deletion batch
C. The snippet is marked as expired but still served until a manual cleanup
D. The snippet is locked and user requests are blocked until deletion finishes

Solution

  1. Step 1: Trace Expiration Worker behavior at Step 4

    The worker deletes expired snippets in batches; deletion is not instantaneous upon TTL expiry.
  2. Step 2: Understand user access during deletion

    Until deletion completes, the snippet remains accessible; no locking or blocking occurs.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Batch deletion delays snippet removal, keeping it accessible briefly [check]
Hint: Expiration deletion is batch-based, not instant [check]
Common Mistakes:
3. If the Progress Worker crashes before persisting a user's video watch progress, what is the exact failure observed by the user when they resume the course?
medium
A. User sees progress reset to zero and must rewatch videos from the start
B. User's progress appears stuck at last persisted checkpoint, missing recent watch time
C. User receives an error message preventing course continuation until retry
D. User's progress is duplicated causing certificate issuance errors

Solution

  1. Step 1: Trace failure impact of Progress Worker crash

    Progress Worker crash before persistence means recent watch time is lost.
  2. Step 2: Evaluate user experience on resume

    System detects missing progress update and returns error preventing continuation (User receives an error message preventing course continuation until retry), rather than silently resetting or duplicating progress.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Crash causes error blocking course continuation until retry [check]
Hint: Crash blocks progress update, user sees error [OK]
Common Mistakes:
4. If the random payload generation step in KSUID is removed, what exactly breaks in the system's ID generation?
medium
A. IDs become non-sortable because timestamp is missing
B. IDs become predictable and collisions increase when multiple nodes generate IDs at the same timestamp
C. IDs become longer and less efficient to store
D. IDs lose their base62 encoding and become invalid

Solution

  1. Step 1: Understand role of random payload in KSUID

    The random payload ensures uniqueness among IDs generated at the same timestamp across nodes.
  2. Step 2: Analyze consequences of removing random payload

    Without random payload, IDs generated at the same timestamp collide, causing duplicates and predictability; timestamp remains, so sortability is intact (A false); length and encoding unchanged (C and D false).
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Random payload prevents collisions at identical timestamps [check]
Hint: Random payload prevents collisions at same timestamp [check]
Common Mistakes:
5. At 10x scale, which component in a time-series database system is most likely to fail first and why?
hard
A. The storage nodes, because disk I/O bandwidth saturates with high write volume
B. The query engine, because complex time-range queries become exponentially slower
C. The ingestion pipeline's partition coordinator, due to increased partition management overhead
D. The metadata service, as it cannot handle the increased number of time-series namespaces

Solution

  1. Step 1: Identify bottlenecks at 10x scale

    High write volume increases partition count and complexity of partition coordination.
  2. Step 2: Evaluate component scalability

    Query engine (A) slows but can be scaled horizontally. Storage nodes (C) face I/O limits but can add disks. Metadata service (D) scales better with caching. Partition coordinator (B) faces coordination overhead and metadata contention, causing first failure.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Partition coordinator overhead grows fastest at scale [check]
Hint: Partition coordination overhead 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