Bird
Raised Fist0
HLDsystem_design~7 mins

Content delivery with CDN in HLD - System Design Guide

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
Problem Statement
When all users request content directly from a single origin server, the server becomes overloaded, causing slow response times and potential downtime. Users far from the server experience high latency and poor performance due to long network distances.
Solution
A Content Delivery Network (CDN) caches copies of content on servers distributed globally near users. When a user requests content, the CDN serves it from the closest cache, reducing load on the origin server and improving response speed by minimizing network distance.
Architecture
Origin
Origin
CDN Edge Servers
CDN Edge Servers
Users Worldwide
Users Worldwide

This diagram shows the origin server delivering content to globally distributed CDN edge servers, which cache content and serve it to users nearby, reducing latency and origin load.

Trade-offs
✓ Pros
Reduces load on the origin server by serving cached content from edge locations.
Improves user experience with lower latency by serving content from nearby servers.
Increases availability and fault tolerance by distributing content across multiple servers.
Scales easily to handle large spikes in traffic without origin server overload.
✗ Cons
Cache invalidation can be complex, leading to stale content if not managed properly.
Additional cost for CDN services and infrastructure.
Dynamic or personalized content may not benefit as much from caching.
Initial setup and configuration require careful planning to optimize cache rules.
Use when your application serves large amounts of static or cacheable content to a global or widely distributed user base, especially if latency and origin load are concerns at traffic levels above thousands of requests per second.
Avoid if your content is highly dynamic and personalized per user with minimal cacheability, or if your user base is small and localized near the origin server, making CDN benefits negligible.
Real World Examples
Netflix
Uses CDN edge servers to cache and deliver video streams close to users, reducing buffering and origin load.
Amazon
Employs CDN to serve product images and static assets globally, improving page load times for shoppers worldwide.
Spotify
Caches music files on CDN nodes near users to provide fast playback and reduce central server demand.
Alternatives
Origin Pull with Cache-Control Headers
Relies on browsers and intermediate proxies to cache content rather than a dedicated CDN network.
Use when: When traffic is low and global distribution is not critical, or when using simple caching without CDN infrastructure.
Peer-to-Peer Content Delivery
Users share content directly with each other instead of relying on centralized CDN servers.
Use when: When building decentralized applications or when reducing CDN costs is a priority.
Summary
CDNs reduce load on origin servers by caching content on globally distributed edge servers.
They improve user experience by serving content from locations closer to users, reducing latency.
CDNs are best for static or cacheable content and large, distributed user bases.

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