Bird
Raised Fist0
HLDsystem_design~25 mins

Content delivery with CDN in HLD - System Design Exercise

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Content Delivery Network (CDN) System
Design covers CDN architecture for static content delivery including caching, cache invalidation, and global distribution. Does not cover dynamic content generation or user authentication.
Functional Requirements
FR1: Deliver static content (images, videos, scripts) to users globally with low latency
FR2: Support at least 1 million concurrent users
FR3: Ensure content is cached close to users to reduce origin server load
FR4: Provide cache invalidation to update content when needed
FR5: Handle sudden traffic spikes without downtime
FR6: Support HTTPS for secure content delivery
Non-Functional Requirements
NFR1: 99.9% availability (less than 8.77 hours downtime per year)
NFR2: API response latency p99 under 100ms for cached content
NFR3: Origin server should not be overwhelmed by requests
NFR4: Content freshness must be maintained with cache TTL and invalidation
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
Edge servers located globally for caching content
Origin servers hosting the original content
Load balancers to distribute user requests
Cache invalidation mechanism
DNS routing to direct users to nearest edge server
HTTPS termination at edge
Design Patterns
Cache-aside pattern for cache population
Geo-DNS or Anycast for routing users to nearest edge
TTL-based cache expiration
Push vs pull CDN content update strategies
Reference Architecture
DNS Resolver
directs to nearestEdge CDN Server Cluster
Cache Storage
Origin Server
Components
DNS Resolver
Geo-DNS or Anycast DNS
Direct users to the nearest edge server based on location
Edge CDN Server Cluster
Distributed edge servers with caching software (e.g., Nginx, Varnish)
Cache and serve content close to users to reduce latency
Cache Storage
In-memory or disk cache on edge servers
Store cached content for fast retrieval
Origin Server
Web servers hosting original static content
Serve content when not available in cache
Cache Invalidation Service
API or messaging system
Update or remove cached content when origin content changes
Load Balancer
Global and local load balancers
Distribute incoming requests evenly across edge servers
Request Flow
1. User requests content via browser.
2. DNS resolver directs user to nearest edge CDN server.
3. Edge server checks cache storage for requested content.
4. If content is cached and fresh, edge server returns content immediately.
5. If content is missing or stale, edge server requests content from origin server.
6. Origin server responds with content.
7. Edge server caches the content and returns it to user.
8. Cache invalidation service updates or removes cached content when origin content changes.
9. Subsequent user requests get fresh content from edge cache.
Database Schema
Not applicable as CDN primarily uses cache storage and origin servers; metadata about cached content includes content key, TTL, last updated timestamp, and invalidation status.
Scaling Discussion
Bottlenecks
Origin server overload during cache misses or traffic spikes
Edge server cache storage limits causing frequent cache evictions
DNS resolver latency or failure affecting user routing
Cache invalidation delays causing stale content delivery
Solutions
Use origin server autoscaling and rate limiting to handle load
Increase edge cache capacity and use efficient eviction policies (LRU)
Deploy multiple DNS resolvers with failover and low latency
Implement near real-time cache invalidation with push updates or short TTLs
Interview Tips
Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.
Explain how CDN reduces latency by caching content close to users
Discuss cache miss handling and origin server protection
Describe cache invalidation strategies to maintain content freshness
Highlight global distribution and DNS routing for scalability
Mention security considerations like HTTPS termination at edge

Practice

(1/5)
1. What is the primary purpose of a Content Delivery Network (CDN)?
easy
A. To store user data permanently
B. To cache content closer to users for faster delivery
C. To replace the origin server completely
D. To encrypt all website content

Solution

  1. Step 1: Understand CDN function

    A CDN stores copies of content in multiple locations worldwide to reduce latency.
  2. Step 2: Identify main benefit

    This caching near users speeds up content delivery and reduces load on the origin server.
  3. Final Answer:

    To cache content closer to users for faster delivery -> Option B
  4. Quick Check:

    CDN = caching near users [OK]
Hint: CDN = cache content near users for speed [OK]
Common Mistakes:
  • Thinking CDN replaces origin server
  • Confusing CDN with data storage
  • Assuming CDN encrypts all content
2. Which of the following is the correct sequence when a user requests content served via a CDN?
easy
A. User -> Origin Server -> CDN -> User
B. Origin Server -> User -> CDN
C. User -> CDN -> Origin Server (if needed) -> CDN -> User
D. User -> CDN -> User -> Origin Server

Solution

  1. Step 1: Trace request flow in CDN

    User first contacts the CDN edge server; if content is cached, it responds immediately.
  2. Step 2: Understand cache miss handling

    If content is not cached, CDN fetches it from the origin server, caches it, then serves user.
  3. Final Answer:

    User -> CDN -> Origin Server (if needed) -> CDN -> User -> Option C
  4. Quick Check:

    Request flow = CDN first, origin fallback [OK]
Hint: User hits CDN first, origin only if cache miss [OK]
Common Mistakes:
  • Assuming user contacts origin server first
  • Ignoring CDN cache miss flow
  • Confusing response direction
3. Consider this simplified code snippet representing a CDN cache check:
cache = {"index.html": "content"}
request = "style.css"

if request in cache:
    response = cache[request]
else:
    response = "fetch from origin"
print(response)
What will be printed?
medium
A. fetch from origin
B. KeyError
C. content
D. None

Solution

  1. Step 1: Check if request key exists in cache

    The request is "style.css" which is not in cache keys (only "index.html" exists).
  2. Step 2: Determine else branch execution

    Since request not found, else branch runs, setting response to "fetch from origin".
  3. Final Answer:

    fetch from origin -> Option A
  4. Quick Check:

    Cache miss prints fetch from origin [OK]
Hint: If key missing in cache, else branch runs [OK]
Common Mistakes:
  • Assuming cache returns default value automatically
  • Expecting KeyError without else
  • Confusing cache keys with values
4. A CDN is configured but users report slow content loading. Which of these is the most likely cause?
medium
A. The CDN is caching all content correctly
B. Users have slow internet unrelated to CDN
C. The origin server is down but CDN cache is fresh
D. The CDN edge servers are geographically far from users

Solution

  1. Step 1: Analyze CDN slow delivery causes

    If CDN edge servers are far from users, latency increases, causing slow loading.
  2. Step 2: Evaluate other options

    The CDN is caching all content correctly means caching works, so unlikely cause. The origin server is down but CDN cache is fresh means cache serves content fast. Users have slow internet unrelated to CDN is user-side, not CDN issue.
  3. Final Answer:

    The CDN edge servers are geographically far from users -> Option D
  4. Quick Check:

    Distance to CDN edge affects speed [OK]
Hint: Far CDN edges cause slow delivery [OK]
Common Mistakes:
  • Blaming origin server when cache is fresh
  • Ignoring CDN server location
  • Assuming caching always fixes speed
5. You want to design a CDN system that handles sudden traffic spikes without overloading the origin server. Which combination of strategies is best?
hard
A. Use aggressive caching with long TTL and multiple CDN edge locations
B. Disable caching and let all requests go to origin server
C. Use a single CDN edge server with short TTL caching
D. Serve content only from origin server with load balancer

Solution

  1. Step 1: Understand traffic spike handling

    Long TTL caching reduces origin hits; multiple edges distribute load geographically.
  2. Step 2: Evaluate options for scalability

    Disable caching and let all requests go to origin server and D overload origin server. Use a single CDN edge server with short TTL caching limits caching benefits and single edge risks bottleneck.
  3. Final Answer:

    Use aggressive caching with long TTL and multiple CDN edge locations -> Option A
  4. Quick Check:

    Long TTL + many edges = scalable CDN [OK]
Hint: Long cache + many edges handle spikes best [OK]
Common Mistakes:
  • Disabling caching under traffic spikes
  • Relying on single edge server
  • Ignoring TTL impact on origin load