Bird
Raised Fist0

Multi-CDN Strategy for Maximum Availability and Geo Coverage

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Multi-CDN Strategy for Maximum Availability and Geo Coverage
Designing a multi-CDN system to maximize content availability and global coverage with low latency
mediumContent Delivery NetworkFreq: medium
Prerequisites:DNSHTTP
⚙️
Functional Requirements
  • Route user content requests to the optimal CDN based on geo-location and performance metrics
  • Automatically failover to secondary CDNs on primary CDN failure or degraded performance
  • Provide real-time health monitoring and performance metrics of each CDN endpoint
  • Support dynamic CDN selection policies configurable per region or content type
  • Log CDN usage and failover events for auditing and analytics
  • Expose APIs for updating CDN configurations and retrieving status
📊
Non-Functional Requirements
  • Support 2 billion daily active users globally
  • Achieve 99.99% availability for content delivery
  • Maintain 100ms P99 latency for CDN selection decision
  • Handle peak write QPS of 1 million requests per second for logging and metrics ingestion
  • Ensure failover detection and rerouting within 500ms
❓
Clarifying Questions to Ask
  • What is the expected peak QPS for content requests globally and per region?
  • Are we responsible for DNS resolution or just CDN selection after DNS?
  • What is the SLA for failover detection and rerouting?
  • What types of content are prioritized (video, images, static files)?
  • Is there a preferred set of CDNs or must the system support arbitrary third-party CDNs?
  • What metrics are available from CDNs for health and performance monitoring?
Out of Scope
✗ Designing the internal CDN infrastructure (edge servers, caching algorithms)
✗ Content origin storage and origin server design
✗ Detailed security mechanisms like DDoS mitigation or encryption protocols
📌
Assumptions
  • 2 billion daily active users globally
  • Each user generates 40 content requests per day
  • Average request size is 100 bytes for logging and metrics
  • Retention period for logs and metrics is 30 days
  • Replication factor for storage is 3
⚡
QPS Calculation
write qps2B users × 40 requests/day ÷ 86400 seconds ≈ 925,926 writes/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2,777,778 writes/sec
read qpsAssuming 10× read amplification for analytics and monitoring: 925,926 × 10 ≈ 9,259,260 reads/sec
💾
Storage Estimate
daily storage gb(2B × 40 × 100 bytes) ÷ (1024³) ≈ 7.45 TB/day
retention storage gb7.45 TB × 30 days ≈ 223.5 TB
with replication gb223.5 TB × 3 replicas ≈ 670.5 TB
🖥️
Server Estimate
api serversAssuming 10K RPS per server: 2,777,778 peak writes ÷ 10K ≈ 278 API servers
metrics ingestionUsing Kafka + Flink, each Kafka broker handles 100K writes/sec: 2,777,778 ÷ 100K ≈ 28 Kafka brokers
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |   User Client  |
          +--------+-------+
                   |
                   v
          +--------+--------+
          |  Global DNS LB  |
          +--------+--------+
                   |
        +----------+-----------+
        |                      |
  +-----v-----+          +-----v-----+
  | CDN A LB  |          | CDN B LB  |
  +-----+-----+          +-----+-----+
        |                      |
  +-----v-----+          +-----v-----+
  | CDN A Edges|         | CDN B Edges|
  +-----------+          +-----------+
        |                      |
        +----------+-----------+
                   |
          +--------v--------+
          |  Health Monitor |
          +--------+--------+
                   |
          +--------v--------+
          | CDN Selection   |
          |   Service       |
          +--------+--------+
                   |
          +--------v--------+
          | Config & Logging|
          +-----------------+
🧩
Components
Global DNS Load Balancer
Directs user DNS queries to the optimal CDN LB based on geo and health
Why thisAWS Route 53 Geo DNS supports latency-based routing with health checks for global scale
Why notUsing a custom DNS server would not scale to billions of queries and lacks global PoPs
CDN Load Balancers (CDN A LB, CDN B LB)
Distribute incoming requests to CDN edge nodes within each CDN provider
Why thisCloudflare and Akamai provide managed LB with global edge presence and failover
Why notSelf-managed LB would increase complexity and reduce reliability at global scale
Health Monitor Service
Continuously monitors CDN endpoints’ health and performance metrics
Why thisPrometheus with custom exporters enables real-time scraping and alerting with sub-second granularity
Why notPolling CDNs via API is too slow and inconsistent for failover within 500ms SLA
CDN Selection Service
Decides which CDN to route requests to based on health, geo, and configured policies
Why thisStateless microservice using Redis for fast lookup and decision caching to meet 100ms P99 latency
Why notUsing a monolithic DB like PostgreSQL would cause high latency and scaling bottlenecks
Config & Logging Service
Manages CDN configuration updates and ingests logs/events for analytics
Why thisKafka for high-throughput log ingestion and Cassandra for scalable config storage with fast writes
Why notElasticsearch is optimized for search, not high write throughput or config consistency
🔄
Data Flow
1
User Client → Global DNS Load Balancer
User DNS query for content domain
DNS LB uses geo and health data to select CDN LB
2
Global DNS Load Balancer → CDN Load Balancer (A or B)
DNS response with CDN LB IP
Selection based on lowest latency and CDN health
3
User Client → CDN Edge Nodes
HTTP content request routed to CDN edges
CDN serves content or fetches from origin
4
Health Monitor → CDN Selection Service
Push health and performance metrics
Enables real-time CDN failover decisions
5
CDN Selection Service → Global DNS Load Balancer
Update routing policies
Adjust DNS responses dynamically on failures
6
CDN Load Balancers → Config & Logging Service
Send logs and usage metrics
For auditing, analytics, and SLA reporting

Practice

(1/5)
1. A global CDN operator needs to prevent a misconfiguration from propagating incorrect BGP routes that could cause widespread internet outages. Which component is primarily responsible for detecting and containing such route leaks?
easy
A. Using a centralized DNS firewall to block suspicious IP prefixes
B. Implementing BGP route filters and prefix limits on edge routers
C. Relying on client-side validation of IP addresses before routing
D. Deploying a distributed cache to store valid routing tables

Solution

  1. Step 1: Identify BGP route filtering role

    BGP route filters and prefix limits on edge routers prevent invalid or excessive route announcements, containing route leaks.

  2. Step 2: Eliminate other options

    DNS firewalls (A) do not control BGP routing; client-side validation (C) is ineffective for routing control; distributed caches (D) do not enforce routing policies.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    BGP route filters contain route leaks at the network edge [check]
Hint: Edge routers enforce BGP filters to block bad routes [check]
Common Mistakes:
2. A system must ingest 1 million events per second with guaranteed ordering per user session and durable storage. Which component best handles this ingestion requirement?
easy
A. Use Redis Pub/Sub for low latency event streaming
B. Use a relational database with batch inserts for durability
C. Use Kafka with partitioning keyed by user session ID
D. Use a simple HTTP endpoint with in-memory queueing

Solution

  1. Step 1: Identify Kafka's role in ingestion

    Kafka supports high-throughput ingestion with partitioning by user session ID, ensuring ordering per session and durability via log storage.

  2. Step 2: Eliminate alternatives

    Relational DB batch inserts can't handle 1M events/sec with ordering guarantees; Redis Pub/Sub lacks durability and ordering guarantees; HTTP with in-memory queueing risks data loss and no ordering guarantees.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Kafka partitions keyed by session ensure ordering and durability [check]
Hint: Kafka partitions preserve ordering per key [check]
Common Mistakes:
3. A web application needs to route incoming HTTP requests to multiple backend services based on URL paths, while also performing authentication and rate limiting. Which component is best suited to handle this?
easy
A. Reverse Proxy that only forwards requests to backend servers without modifying requests
B. Load Balancer that distributes traffic evenly across servers without inspecting HTTP headers
C. API Gateway that routes requests, enforces authentication, and applies rate limiting policies
D. DNS-based load balancing that resolves domain names to multiple IP addresses randomly

Solution

  1. Step 1: Identify component roles

    Load Balancers distribute traffic but do not inspect or modify requests; Reverse Proxies forward requests but lack built-in authentication and rate limiting; DNS-based load balancing is coarse and lacks request-level control.

  2. Step 2: Match scenario requirements

    API Gateway supports routing based on URL paths, authentication, and rate limiting, fulfilling all requirements.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    API Gateway handles routing and policies at HTTP layer [check]
Hint: API Gateway = routing + auth + rate limiting [check]
Common Mistakes:
4. 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:
5. At 10x scale, which component in a distributed lock system using ZooKeeper is most likely to fail first and why?
hard
A. ZooKeeper ensemble leader, due to increased write load and session management overhead
B. Clients, because they cannot handle the increased lock acquisition requests
C. Network routers, because of increased traffic causing packet loss
D. Storage backend, because ephemeral nodes consume excessive disk space

Solution

  1. Step 1: Identify ZooKeeper leader role

    The leader handles all write requests and session heartbeats, becoming a bottleneck under high scale.

  2. Step 2: Evaluate other components

    Clients (A) can be scaled horizontally; network routers (C) are less likely the first bottleneck; ephemeral nodes (D) are lightweight and cleaned up automatically.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Leader bottleneck due to write and session overhead [check]
Hint: ZooKeeper leader handles all writes -> first bottleneck [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