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
45 min · senior
senior

You are designing the content delivery architecture for a 50M DAU video streaming startup. The origin servers host all video content and metadata. Users expect P99 latency under 200ms globally, with encrypted content delivery (TLS everywhere). Offline delivery is a future requirement. The origin servers are in a single region. Design a system that explains why a CDN is necessary and what origin servers alone cannot achieve.

Constraints
  • Global P99 latency < 200ms for 50M DAU
  • End-to-end encryption (TLS) required
  • Origin servers located in a single region
  • Offline content delivery support planned
  • High throughput: 10Gbps+ sustained traffic
  • Cost efficiency at scale
📋
Guided Steps
1/5
Step 1
Identify the core limitations of origin servers alone
What are the key scalability and latency challenges if all 50M DAU hit origin servers directly?
💡 Hint
Consider network latency, bandwidth bottlenecks, and single-region constraints.
Key Decision
Origin servers in a single AWS us-east-1 region cannot meet global P99 < 200ms latency due to physical distance and bandwidth limits; direct origin hits cause high load and increased failure rates.
Interviewer Expectation
Mid: Names latency and bandwidth as issues. Senior: Quantifies latency impact by region and explains origin server overload leading to cascading failures under peak load.
⚠️Common Wrong Answer
Assuming origin servers can scale infinitely with autoscaling groups, ignoring network latency and cross-region bandwidth constraints, leading to poor global user experience.
Step 2
Explain why a CDN is necessary and what it provides
What capabilities does a CDN add that origin servers alone cannot provide at this scale?
💡 Hint
Think about caching, edge locations, TLS termination, and traffic offload.
Key Decision
Using a global CDN like Cloudflare or Akamai places edge caches close to users, reducing latency by serving cached content locally and offloading origin servers, while handling TLS termination at the edge.
Interviewer Expectation
Mid: Mentions caching and edge locations. Senior: Explains TLS termination at edge reduces origin load and latency, and how CDN handles cache invalidation and offline delivery support.
⚠️Common Wrong Answer
Using a simple reverse proxy without global edge caching, resulting in origin overload and high latency for distant users.
Step 3
Design the content delivery flow with CDN and origin
Describe the request flow from client to CDN edge to origin server on cache hit and miss.
💡 Hint
Consider DNS resolution, cache lookup, origin fetch, and response paths.
Key Decision
Client DNS resolves to nearest CDN PoP; on cache hit, CDN edge serves content directly; on miss, CDN edge fetches from origin over TLS, caches response, then serves client, reducing origin load and latency.
Interviewer Expectation
Mid: Describes basic cache hit/miss flow. Senior: Details DNS-based geo-routing, TLS session reuse at edge, and cache revalidation strategies to maintain freshness and security.
⚠️Common Wrong Answer
Ignoring DNS geo-routing and assuming clients always connect to origin, causing high latency and origin overload.
Step 4
Plan for offline delivery and encrypted content
How does the system support offline content delivery while maintaining encryption and security?
💡 Hint
Think about DRM, prefetching, and secure local storage.
Key Decision
Use DRM-enabled encrypted content packaged with AES-128 or Widevine, prefetch content to client devices via CDN edge, and store securely on device; origin servers provide license keys via secure APIs.
Interviewer Expectation
Mid: Mentions offline caching. Senior: Explains DRM integration, secure key exchange via origin APIs, and how CDN edge supports prefetching without exposing keys.
⚠️Common Wrong Answer
Caching unencrypted content on client devices or relying on origin servers for offline delivery, causing security breaches and poor offline UX.
Step 5
Define 3 core API endpoints for client-CDN-origin interaction
Sketch 3 essential API endpoints clients use to interact with the CDN and origin servers.
💡 Hint
How does the client request cached content?How does the client fetch fresh metadata or content on cache miss?How does the client acknowledge receipt or report errors?
Key Decision
1) GET /content/{id} served by CDN edge with cache fallback to origin; 2) GET /metadata/{id} from origin with CDN caching; 3) POST /acknowledgement to origin for delivery confirmation and error reporting.
Interviewer Expectation
Mid: Lists basic GET endpoints. Senior: Explains CDN edge caching for content and metadata, origin fallback, and POST endpoint for client telemetry and error handling.
⚠️Common Wrong Answer
Designing only origin endpoints without CDN integration, causing unnecessary origin load and latency.
🔌
API Design Challenge
Sketch 3 core API endpoints that clients use to interact with the CDN and origin servers.
Hints
  • How does the client request and receive cached content?
  • How does the client fetch fresh content or metadata when cache misses occur?
  • How does the client acknowledge content receipt or report errors?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Quantitative reasoning about latency and bandwidth limits of origin servers
  • Explanation of CDN edge caching and TLS termination benefits
  • Detailed request flow including DNS geo-routing and cache hit/miss handling
  • Design of API endpoints integrating CDN and origin interactions
Good to Have - 30%
  • Discussion of DRM and encrypted offline delivery mechanisms
  • Cache invalidation and revalidation strategies
  • Cost and failure mode considerations for origin overload
Bonus - 10%
  • Insights on CDN multi-CDN strategies for availability
  • Advanced TLS session reuse and certificate management at edge
Anti-patterns to Avoid
Assuming origin servers can handle global traffic without latency or bandwidth issues, leading to poor user experience and outages: This causes high latency for distant users and overloads origin servers, resulting in failures.
Using a simple reverse proxy without global edge caching, causing origin overload and high latency: Without edge caches, all requests hit origin, increasing load and latency.
Ignoring TLS termination at CDN edge, resulting in increased origin CPU load and latency: Origin servers bear full cryptographic overhead, reducing scalability.
Designing APIs that bypass CDN caching, increasing origin load and latency: This negates CDN benefits and causes origin bottlenecks.
Caching unencrypted content on client devices or relying on origin servers for offline delivery, causing security breaches and poor offline UX: Leads to data leaks and poor offline performance.
✅
Model Answer
▼ Reveal

Origin servers alone cannot meet global latency and scalability demands for 50M DAU video streaming due to physical distance, bandwidth limits, and TLS overhead. A global CDN with edge caching and TLS termination reduces latency and origin load. DNS geo-routing directs clients to nearest PoP. Cache hit serves content locally; cache miss fetches from origin securely. DRM-enabled encrypted content and prefetching enable secure offline playback. APIs integrate CDN caching and origin fallback with telemetry support.

Key Decisions
  • Use AWS us-east-1 for origin servers but rely on global CDN edges to meet P99 latency < 200ms
  • Leverage Cloudflare or Akamai CDN for edge caching and TLS termination to offload origin servers
  • Implement DNS geo-routing to direct clients to nearest CDN PoP for optimal latency
  • On cache miss, CDN edge fetches content from origin over TLS, caches it, then serves client
  • Integrate DRM with AES-128 or Widevine to encrypt content for secure offline playback
  • Prefetch content to client devices via CDN edges and store securely to support offline use
  • Design APIs so GET /content/{id} is served by CDN edge with origin fallback, GET /metadata/{id} served by origin with CDN caching, and POST /acknowledgement for client telemetry and error reporting
  • Origin servers in a single region cannot meet global P99 latency < 200ms due to physical distance and bandwidth limits
  • Global CDN (e.g., Cloudflare, Akamai) provides edge caching close to users, reducing latency and origin load
  • CDN edge terminates TLS sessions, offloading cryptographic overhead from origin servers
  • DNS-based geo-routing directs clients to nearest CDN PoP for optimal latency
  • Cache hit serves content directly from CDN edge, cache miss triggers origin fetch over TLS with caching
  • DRM-enabled encrypted content supports offline delivery securely with license keys fetched from origin APIs
  • Prefetching content to client devices via CDN edges enables offline playback without origin dependency
  • API endpoints include GET /content/{id} (CDN edge), GET /metadata/{id} (origin with CDN caching), POST /acknowledgement (origin telemetry)
  • Cache invalidation and revalidation strategies maintain content freshness and security at scale
  • Cost efficiency achieved by reducing origin bandwidth and compute load via CDN offload

Practice

(1/5)
1. In a request trace, at step 4 the latency monitoring component records the request's completion time. If the request took 120ms but the P95 latency threshold is 100ms, what state does the monitoring component mark for this request?
easy
A. Request is ignored because it is below P99 latency
B. Request is marked as within acceptable latency
C. Request is marked as exceeding P95 latency threshold
D. Request is marked as failed due to timeout

Solution

  1. Step 1: Compare request latency to P95 threshold

    The request latency (120ms) exceeds the P95 threshold (100ms), so it is in the slowest 5% tail.

  2. Step 2: Monitoring component's marking logic

    Requests exceeding P95 latency are flagged to identify performance degradation; it is not ignored or marked as failed unless timeout occurs.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    120ms > 100ms P95 -> marked as exceeding P95 latency [check]
Hint: Latency > P95 threshold -> mark as slow request [OK]
Common Mistakes:
2. If the authentication service in a client-server system becomes unavailable, what is the exact failure mode experienced by clients attempting to log in?
medium
A. Clients receive a generic server error but can retry immediately without data loss
B. Clients are authenticated locally by the server, so login proceeds without interruption
C. Clients' login requests hang until timeout, then receive authentication failure with no retry
D. Clients are redirected to a backup authentication service automatically

Solution

  1. Step 1: Understand authentication dependency

    The server relies on the authentication service for validating credentials; if unavailable, requests cannot be processed.

  2. Step 2: Trace failure impact

    Without authentication service, login requests hang waiting for response until timeout, then fail with no automatic retry or fallback.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Unavailable auth service causes login hang then failure [check]
Hint: No auth service -> login hangs then fails, no fallback [check]
Common Mistakes:
3. If the Kafka cluster responsible for location update ingestion becomes unavailable, what is the immediate failure observed in the system?
medium
A. Location updates queue up in the WebSocket Server memory until Kafka recovers
B. WebSocket Server blocks on sending updates, causing client-side UI to freeze
C. Location updates are lost silently without any retry or backpressure
D. Clients receive stale location data but no error is shown

Solution

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

    Kafka decouples ingestion; if unavailable, producers (WebSocket Server) cannot push messages.

  2. Step 2: Trace failure impact

    WebSocket Server buffers updates temporarily but memory is limited; blocking would cause backpressure but usually async buffers exist.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka outage causes buffering, not silent loss or blocking immediately [check]
Hint: Kafka outage -> WebSocket buffers updates temporarily [check]
Common Mistakes:
4. If the Kafka cluster responsible for connection event streaming goes down, what exactly breaks in the system's connection request processing?
medium
A. Connection requests are lost immediately with no retry or buffering
B. Connection requests are redirected to a backup database that duplicates all writes
C. Connection requests block the user synchronously until Kafka recovers, causing UI timeouts
D. Connection requests are accepted but downstream services do not receive updates, causing stale connection graphs

Solution

  1. Step 1: Understand Kafka's role in event streaming

    Kafka buffers and reliably delivers connection events to downstream services asynchronously.

  2. Step 2: Trace failure impact

    If Kafka is down, writes to Kafka fail but connection requests may still be accepted at the API layer; however, downstream consumers do not get updates, causing stale graph state.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka down -> downstream stale, no immediate request loss [check]
Hint: Kafka failure stalls downstream, not immediate request loss [OK]
Common Mistakes:
5. At 10x scale, which component in a range-sharded database system is most likely to fail first and why?
hard
A. The shard directory service, because it becomes a centralized bottleneck for routing requests
B. The shard servers holding the highest traffic ranges, due to uneven load and hotspotting
C. The network load balancer, because it cannot handle the increased number of shards
D. The client-side hashing logic, because it cannot scale to map keys to shards

Solution

  1. Step 1: Identify load distribution in range sharding

    Range sharding partitions data by key ranges, causing uneven load if some ranges are hotter.

  2. Step 2: Analyze scaling impact

    At 10x scale, shards with hot ranges become overloaded first, causing failures before other components.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Range shard hotspots cause uneven load and early failures [check]
Hint: Range shards fail at hotspots due to uneven load [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