Bird
Raised Fist0

CDN Architecture - Edge Nodes, Points of Presence, Origin Pull vs Push

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
CDN Architecture - Edge Nodes, Points of Presence, Origin Pull vs Push
Design a scalable CDN with edge nodes and PoPs supporting origin pull and push models
mediumContent Delivery NetworkFreq: high
Prerequisites:DNSHTTP
⚙️
Functional Requirements
  • Serve static and dynamic content with low latency to global users via edge nodes.
  • Support origin pull model where edge nodes fetch content on cache miss from origin servers.
  • Support origin push model where origin proactively pushes content to edge nodes.
  • Implement cache invalidation and content freshness mechanisms across PoPs.
  • Load balance user requests to nearest PoP using DNS or Anycast routing.
  • Provide metrics and logging for cache hit ratio, latency, and bandwidth usage.
📊
Non-Functional Requirements
  • Support 2 billion daily active users globally.
  • Achieve 99.99% availability for content delivery.
  • Ensure 100ms P99 latency for cache hits at edge nodes.
  • Handle peak write QPS of 2.8M (content updates) and read QPS of 10M (content requests).
  • Scale to 100+ PoPs worldwide with automated failover.
❓
Clarifying Questions to Ask
  • What is the expected content size distribution (small images vs large videos)?
  • What is the update frequency of content at the origin (write QPS)?
  • Are we supporting dynamic content caching or only static assets?
  • What is the geographic distribution of users and PoPs?
  • Is the CDN expected to support live streaming or just on-demand content?
  • What is the SLA for cache freshness and invalidation latency?
Out of Scope
✗ Design of origin content management systems (CMS).
✗ Detailed DNS server implementation.
✗ End-user device or browser caching strategies.
✗ Security features like DDoS mitigation or TLS termination.
📌
Assumptions
  • 2 billion DAU globally.
  • Each user requests 40 content objects per day on average.
  • Average content object size is 100 KB.
  • Content update rate at origin is 0.5% of total content per day.
⚡
QPS Calculation
write qps2B users × 40 objects × 0.005 updates / 86400 sec ≈ 925K writes/sec
peak write qpsAssuming 3× peak factor → 2.8M writes/sec
read qps2B users × 40 objects / 86400 sec ≈ 925K reads/sec average, peak 10M reads/sec
💾
Storage Estimate
daily storage2B × 40 × 100 KB = 8 PB/day raw data
retention days7
total storage8 PB × 7 days = 56 PB
with replication56 PB × 3 replicas = 168 PB total storage
🖥️
Server Estimate
edge nodesAssuming 100 PoPs × 100 edge nodes each = 10,000 edge servers
origin serversTo handle 2.8M writes/sec peak, ~500 origin servers with sharded storage clusters
🏗️
Architecture Diagram
Architecture Diagram
          +----------------------+
          |      DNS Resolver     |
          +----------+-----------+
                     |
          +----------v-----------+
          |  Global Load Balancer |
          +----------+-----------+
                     |
        +------------+-------------+
        |                          |
  +-----v-----+              +-----v-----+
  |  PoP 1    |              |  PoP N    |
  | Edge Node |              | Edge Node |
  +-----+-----+              +-----+-----+
        |                          |
        +------------+-------------+
                     |
          +----------v-----------+
          |     Origin Servers    |
          +----------------------+
🧩
Components
DNS Resolver
Directs user requests to nearest PoP based on geo-DNS or Anycast routing
Why thisGeoDNS with latency-based routing using AWS Route 53 or Google Cloud DNS reduces user latency by directing to closest PoP
Why notSimple round-robin DNS does not consider user location, increasing latency and reducing performance
Global Load Balancer
Balances incoming requests across multiple PoPs and edge nodes within PoPs
Why thisAWS Global Accelerator or Google Cloud Load Balancer supports global Anycast IPs and health checks for real-time failover
Why notDNS-only load balancing lacks real-time health checks and dynamic failover capabilities
Edge Nodes
Cache content close to users, serve requests with low latency, and handle cache misses
Why thisNginx or Varnish with local SSD caches provide sub-100ms P99 latency for cached content
Why notCentralized caching increases latency and bandwidth costs due to longer network paths
Points of Presence (PoPs)
Geographically distributed data centers hosting edge nodes to reduce latency and improve availability
Why thisUsing AWS CloudFront PoPs or Akamai PoPs ensures global coverage and redundancy
Why notSingle-region deployment causes high latency and single points of failure
Origin Servers
Authoritative source of content; serves cache misses and pushes updates to edge nodes
Why thisHighly available object storage like Amazon S3 or Google Cloud Storage integrated with CDN supports scalability and durability at 2.8M writes/sec
Why notTraditional web servers lack scalability and durability at high write QPS
Cache Invalidation Service
Propagates content invalidation and freshness updates from origin to edge nodes
Why thisKafka streams enable scalable, ordered, and reliable invalidation message delivery across distributed edge nodes
Why notPolling-based invalidation causes stale caches and higher latency
Monitoring & Metrics Service
Collects cache hit ratios, latency, bandwidth usage, and error rates across PoPs
Why thisPrometheus + Grafana stack provides real-time observability with alerting and dashboards
Why notManual log aggregation delays detection of outages or performance degradation
🔄
Data Flow
1
User → DNS Resolver
User DNS query resolves to nearest PoP IP
GeoDNS or Anycast routes user to closest PoP
2
User → Edge Node
User HTTP request sent to edge node in PoP
Edge node attempts to serve from local cache
3
Edge Node → Origin Server
On cache miss, edge node pulls content from origin (origin pull)
Content cached locally after fetch
4
Origin Server → Cache Invalidation Service
Origin pushes content updates and invalidation messages
Invalidation messages propagate to edge nodes
5
Cache Invalidation Service → Edge Nodes
Edge nodes receive invalidation and refresh cache proactively (origin push)
Ensures content freshness across PoPs
6
Monitoring & Metrics Service → Operations Team
Aggregated metrics and alerts sent to operations for monitoring
Enables proactive detection and resolution of issues

Practice

(1/5)
1. A public API needs to support multiple client versions simultaneously without breaking existing integrations. Which versioning strategy best isolates client requests to avoid accidental breaking changes?
easy
A. Use content negotiation with Accept header media types to specify version
B. Use a custom HTTP header like X-API-Version to specify the version
C. Embed the version number in the URL path, e.g., /v1/resource
D. Rely on query parameters like ?version=1 to indicate API version

Solution

  1. Step 1: Identify version isolation requirements

    Embedding version in the URL path clearly separates client requests by version, preventing accidental routing to incompatible handlers.

  2. Step 2: Evaluate alternatives

    Custom headers and content negotiation can be ignored or mishandled by intermediaries or caches, risking breaking changes. Query parameters are less explicit and can cause caching issues.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    URL versioning cleanly isolates versions in routing paths [check]
Hint: URL path versioning isolates clients cleanly [check]
Common Mistakes:
2. A system must handle millions of short video uploads per day, ensuring fast ingestion and metadata extraction without blocking the user. Which component is best suited to decouple upload ingestion from processing?
easy
A. Use a distributed message queue like Kafka to buffer uploads for asynchronous processing
B. Use a relational database to store uploads synchronously during user upload
C. Use a CDN edge cache to store uploads temporarily before processing
D. Use a REST API gateway that directly triggers video transcoding synchronously

Solution

  1. Step 1: Identify ingestion decoupling need

    Relational DB (A) blocks user upload due to synchronous writes; CDN (C) caches for delivery, not ingestion; REST API (D) triggers blocking transcoding.

  2. Step 2: Choose buffering component

    Kafka (B) buffers uploads asynchronously, enabling fast user response and reliable processing.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka buffers uploads asynchronously for scalable ingestion [check]
Hint: Buffer uploads asynchronously with Kafka queue [OK]
Common Mistakes:
3. For a high-throughput system requiring SSL termination and HTTP header manipulation, which architecture is more appropriate and why?
medium
A. Use a Reverse Proxy for SSL termination and header manipulation because it operates at the HTTP layer with fine-grained control
B. Use an API Gateway for SSL termination and header manipulation because it is optimized for high throughput
C. Use a Load Balancer for SSL termination and header manipulation because it handles traffic efficiently
D. Use DNS load balancing to distribute SSL termination across multiple servers

Solution

  1. Step 1: Identify component capabilities

    Load Balancers typically operate at transport layer and may support SSL termination but lack detailed HTTP header manipulation; API Gateways add overhead and are less optimized for raw throughput; DNS load balancing does not handle SSL termination.

  2. Step 2: Match requirement to component

    Reverse Proxy operates at HTTP layer, supports SSL termination and header manipulation efficiently, suitable for high throughput.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Reverse Proxy = HTTP layer control + SSL termination [check]
Hint: Reverse Proxy = SSL termination + HTTP header control [check]
Common Mistakes:
4. At 10x scale, which component is most likely to fail first due to caching, and why?
medium
A. The database, because it cannot handle the increased write load from cache invalidations
B. The network, because cache synchronization traffic overwhelms bandwidth
C. The cache, because it runs out of memory due to increased data volume
D. The application servers, because cache misses cause excessive DB queries

Solution

  1. Step 1: Identify scaling impact on cache

    At 10x scale, cache memory pressure increases due to more data and entries.

  2. Step 2: Evaluate failure likelihood

    Cache memory exhaustion is common before DB or network fail due to caching.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Cache memory limits cause failure first at scale [check]
Hint: Cache memory exhaustion causes failure first at scale [check]
Common Mistakes:
5. If the load balancer's health check component is removed, what exact failure occurs when a backend server crashes unexpectedly?
medium
A. The load balancer continues sending requests to the crashed backend, causing client timeouts
B. Clients receive error responses directly from the crashed backend server
C. The backend server automatically restarts and recovers without affecting traffic
D. The load balancer immediately detects the crash and reroutes traffic seamlessly

Solution

  1. Step 1: Understand health check role

    The health check component detects backend server crashes and informs the load balancer to stop routing traffic to failed servers.

  2. Step 2: Trace failure without health checks

    Without health checks, the load balancer is unaware of backend crashes and continues routing requests to the failed server, causing client requests to hang or timeout (The load balancer continues sending requests to the crashed backend, causing client timeouts).

  3. Step 3: Eliminate other options

    The load balancer immediately detects the crash and reroutes traffic seamlessly is false because detection is missing. The backend server automatically restarts and recovers without affecting traffic is unrelated to load balancer behavior. Clients receive error responses directly from the crashed backend server is incorrect because crashed servers cannot respond.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    No health checks -> load balancer sends requests to crashed backend causing timeouts [check]
Hint: No health checks -> requests sent to dead servers cause timeouts [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