Bird
Raised Fist0

Why CDN Exists and What Origin Servers Cannot Do Alone

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Why CDN Exists and What Origin Servers Cannot Do Alone
Explaining the necessity of CDNs beyond origin servers for scalable, low-latency content delivery
mediumContent Delivery NetworkFreq: common
Prerequisites:DNSHTTP
⚙️
Functional Requirements
  • Serve static and dynamic content with low latency globally
  • Cache content at edge locations to reduce origin load
  • Support cache invalidation and content freshness controls
  • Handle high read traffic spikes without degrading performance
  • Provide fault tolerance and availability during origin outages
  • Support HTTPS and HTTP/2 for secure and efficient delivery
📊
Non-Functional Requirements
  • Support 2 billion daily active users globally
  • Achieve 99.99% availability SLA for content delivery
  • Maintain 100ms P99 latency for cache hits at edge
  • Handle peak read QPS of at least 10 million requests/sec
  • Ensure cache consistency within 5 minutes of origin update
❓
Clarifying Questions to Ask
  • What types of content are primarily served (static, dynamic, video)?
  • What is the geographic distribution of users and edge locations?
  • What is the expected cache hit ratio at the CDN edges?
  • How frequently does content update requiring cache invalidation?
  • Are there any compliance or security requirements (e.g., GDPR)?
  • What protocols and encryption standards must be supported?
Out of Scope
✗ Designing origin server internals or backend application logic
✗ Detailed DNS infrastructure design beyond basic routing
✗ Real-time streaming or live video delivery specifics
✗ Client-side rendering or browser caching strategies
📌
Assumptions
  • 2 billion daily active users (DAU)
  • Each user generates 40 content requests per day
  • Average content size is 100 KB per request
  • Peak traffic is 2x average traffic during peak hours
⚡
QPS Calculation
write qps2B users × 40 requests/day ÷ 86400 sec/day ≈ 925,926 req/sec
peak write qps925,926 × 2 (peak factor) ≈ 1,851,852 req/sec
read qpsAssuming 90% cache hit ratio, read QPS at edge ≈ 1,666,666 req/sec
💾
Storage Estimate
daily storage2B × 40 × 100 KB = 8 PB/day raw data
retention days7
total storage8 PB × 7 = 56 PB
with replication56 PB × 3 (replication factor) = 168 PB
🖥️
Server Estimate
origin serversTo handle 1.85M req/sec writes, need ~200 origin servers (each 10K req/sec capacity)
edge cache nodesTo handle 1.67M req/sec reads with 100ms latency, ~1000 edge nodes globally (each 2K req/sec)
🏗️
Architecture Diagram
Architecture Diagram
       +------------+
       |   Clients  |
       +-----+------+
             | DNS resolves to nearest edge
             v
       +-----+------+
       | CDN Edges  |
       +-----+------+
             | Cache hit: serve content
             | Cache miss: forward request
             v
       +-----+------+
       | Origin Srv |
       +------------+
🧩
Components
DNS Resolver
Directs client requests to the nearest CDN edge based on geo-location
Why thisRoute53 Geo DNS supports latency-based routing and health checks for global distribution
Why notTraditional static DNS cannot dynamically route based on client location or edge health
CDN Edge Cache (e.g., Cloudflare, Akamai)
Caches content close to users to reduce latency and origin load
Why thisEdge caches reduce origin traffic by 90%+ and provide sub-100ms latency globally
Why notOrigin servers alone cause high latency and cannot scale to global read QPS
Origin Servers
Authoritative source of content and handles cache misses and dynamic content
Why thisCentralized origin ensures content freshness and handles writes/updates
Why notOrigin alone cannot handle global scale reads or provide low latency worldwide
Cache Invalidation Service
Propagates content updates and invalidates stale cache entries at edges
Why thisEnsures cache consistency within minutes using pub/sub (e.g., Kafka) and edge APIs
Why notTTL-only caches cause stale content; manual invalidation is error-prone and slow
Load Balancer (e.g., ELB, NGINX)
Distributes incoming requests evenly across origin servers
Why thisPrevents origin overload and enables horizontal scaling
Why notDNS round-robin lacks health checks and fine-grained load distribution
🔄
Data Flow
1
Client → DNS Resolver
Client queries DNS for content domain
DNS returns nearest healthy CDN edge IP based on geo and latency
2
Client → CDN Edge Cache
Client sends HTTP request to edge
Edge attempts to serve content from local cache
3
CDN Edge Cache → Client
If cache hit, edge returns content immediately
Achieves sub-100ms latency for majority of requests
4
CDN Edge Cache → Origin Servers
If cache miss, edge forwards request to origin
Origin serves fresh content or dynamic data
5
Origin Servers → CDN Edge Cache
Origin returns content to edge
Edge caches content for future requests
6
Cache Invalidation Service → CDN Edge Cache
Sends invalidation messages on content update
Edges purge or refresh stale cache entries
7
Client → CDN Edge Cache
Subsequent requests served from updated cache
Ensures content freshness and low latency

Practice

(1/5)
1. In a file storage system, at step 3 the client requests a file write. What happens inside the metadata server at this step?
easy
A. The metadata server sends the file data to object storage for persistence.
B. The metadata server writes the file data blocks directly to disk.
C. The metadata server updates the file's inode and directory entries to reflect the new write.
D. The metadata server caches the entire file in memory without updating disk metadata.

Solution

  1. Step 1: Understand metadata server role in file write

    The metadata server manages file metadata like inodes and directory entries, not the actual data blocks.

  2. Step 2: Trace what happens at step 3

    On a write request, the metadata server updates the inode and directory metadata to reflect changes; data blocks are handled separately by storage nodes.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Metadata server updates inode, not data blocks [check]
Hint: Metadata server updates metadata, not file data blocks [check]
Common Mistakes:
2. In the photo feed generation flow, at step 4 the Feed Worker fetches stories from the Stories Service cache. What happens if the cache TTL for a user's stories has expired at this step?
easy
A. The Feed Worker asynchronously refreshes the cache but returns an empty stories section immediately
B. The Feed Worker triggers a synchronous fetch from the Stories DB and blocks until fresh stories are retrieved
C. The Feed Worker returns stale stories from a backup cache without fetching fresh data
D. The Feed Worker skips stories for that user and proceeds with only photo posts in the feed

Solution

  1. Step 1: Trace Feed Worker behavior at cache miss

    When TTL expires, the cache is stale. The Feed Worker must avoid blocking feed generation.

  2. Step 2: Understand asynchronous cache refresh

    To maintain low latency, the Feed Worker returns empty stories immediately and triggers async cache refresh. Blocking fetch (B) would increase latency. Returning stale data (A) risks outdated content. Skipping stories silently (C) loses user experience.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Async cache refresh avoids blocking feed generation [check]
Hint: Async cache refresh avoids blocking feed generation [OK]
Common Mistakes:
3. A company wants to conduct a post-mortem after a major outage without blaming individuals, focusing on systemic issues and actionable improvements. Which component best supports this blameless culture approach?
easy
A. A detailed blame assignment report highlighting individual errors
B. An automated alert system that escalates to management immediately
C. A structured timeline tool capturing events and decisions neutrally
D. A punitive review board to enforce accountability

Solution

  1. Step 1: Identify blameless culture requirements

    The approach requires neutral, factual event capture without assigning blame to individuals.

  2. Step 2: Evaluate components for neutrality and actionability

    A structured timeline tool capturing events and decisions neutrally provides a structured timeline tool that records events and decisions neutrally, enabling root cause analysis without blame.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Neutral event timelines enable blameless post-mortems [check]
Hint: Blameless means neutral facts, not blame assignment [check]
Common Mistakes:
4. Without Kafka in the messaging pipeline, what exactly breaks in message delivery when Bob's server crashes during Alice's send?
medium
A. Messages are duplicated and delivered multiple times to Bob
B. Alice's send blocks waiting for Bob's server response; if Bob crashes, message is lost with no retry
C. Messages are encrypted incorrectly causing delivery failure
D. Alice's client retries indefinitely causing network congestion

Solution

  1. Step 1: Understand Kafka's role in decoupling and durability

    Kafka buffers messages asynchronously, so Alice's send returns quickly. Without Kafka, Alice's server must synchronously contact Bob's server.

  2. Step 2: Trace failure when Bob's server crashes

    If Bob's server crashes, Alice's send blocks waiting for response, then message is lost with no retry logic. Duplication (A) or encryption issues (C) are unrelated. Indefinite retries (D) are not default behavior.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    No Kafka -> synchronous send blocks and loses message on Bob crash [check]
Hint: No Kafka -> synchronous send blocks and loses message on failure [OK]
Common Mistakes:
5. At 10x scale, which component in an idempotent payment API system is most likely to become the bottleneck first, and why?
hard
A. The payment processor, because it cannot handle increased transaction volume
B. The client SDK, as it struggles to generate unique idempotency keys at scale
C. The API gateway, because it cannot route 10x more requests efficiently
D. The idempotency key store, due to synchronous writes and read-after-write consistency requirements

Solution

  1. Step 1: Identify idempotency store workload at scale

    Idempotency store must synchronously write and read keys with strong consistency, creating a high throughput bottleneck.

  2. Step 2: Compare other components

    Payment processors can be scaled horizontally; API gateways are stateless and scalable; client SDKs generating keys is lightweight.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Synchronous idempotency store writes limit scaling first [check]
Hint: Idempotency store sync writes throttle scaling first [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