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

You are designing a Content Delivery Network (CDN) for a startup with 50 million daily active users globally. The system must deliver static and dynamic content with P99 latency under 200ms worldwide. The CDN must support encrypted content delivery (TLS everywhere), offline content availability for mobile users, and handle sudden traffic spikes gracefully. The architecture should balance between origin pull and push strategies to optimize freshness and bandwidth costs.

Constraints
  • P99 latency for content delivery must be under 200ms globally
  • TLS encryption mandatory for all content delivery (HTTPS everywhere)
  • Offline content availability for mobile users with intermittent connectivity
  • Support for sudden traffic spikes up to 5x baseline load
  • Global distribution with multiple Points of Presence (PoPs) and edge nodes
  • Cost optimization between origin bandwidth and cache storage
📋
Guided Steps
1/5
Step 1
Designing the Edge Node and PoP Hierarchy
How would you architect the hierarchy of edge nodes and Points of Presence to meet global low-latency and high availability requirements?
💡 Hint
Consider geographic distribution, proximity to users, and failure isolation between PoPs.
Key Decision
Use AWS CloudFront-like multi-tier PoP architecture with AWS Regional Edge Caches and local edge nodes close to users to reduce latency and isolate failures.
Interviewer Expectation
Mid: Names multi-tier PoP and edge nodes. Senior: Explains geographic distribution trade-offs, failure isolation benefits, and how regional edge caches reduce origin load.
⚠️Common Wrong Answer
Single global cache layer - leads to high latency for distant users and single points of failure.
Step 2
Origin Pull vs Push Content Delivery Strategy
Which content delivery strategy would you choose between origin pull and origin push, and why?
💡 Hint
Think about freshness requirements, bandwidth costs, and cache storage constraints.
Key Decision
Adopt a hybrid approach: origin pull for dynamic or less popular content to save bandwidth, and origin push (pre-warming) for popular static content to ensure freshness and reduce latency.
Interviewer Expectation
Mid: Describes origin pull and push basics. Senior: Explains hybrid trade-offs, cache storage cost impact, and how push reduces cold start latency for hot content.
⚠️Common Wrong Answer
Only origin pull - causes high latency and origin overload during traffic spikes.
Step 3
Ensuring Encrypted Content Delivery with TLS Everywhere
How would you implement TLS encryption across the CDN while maintaining low latency and scalability?
💡 Hint
Consider certificate management, TLS termination points, and hardware acceleration options.
Key Decision
Terminate TLS at edge nodes using AWS Certificate Manager with automated certificate rotation and use TLS 1.3 with hardware TLS accelerators (e.g., AWS Nitro Enclaves) to minimize handshake latency.
Interviewer Expectation
Mid: Mentions TLS termination at edge. Senior: Details certificate automation, TLS 1.3 benefits, and hardware acceleration to meet P99 latency SLA.
⚠️Common Wrong Answer
Terminate TLS only at origin - adds latency and increases origin load.
Step 4
Offline Content Availability for Mobile Users
How would you design the CDN to support offline content availability for mobile users with intermittent connectivity?
💡 Hint
Think about local caching strategies, sync mechanisms, and cache invalidation for offline mode.
Key Decision
Implement client-side persistent caching with Service Workers and IndexedDB for offline content, combined with edge node cache hints via HTTP Cache-Control headers and background sync APIs.
Interviewer Expectation
Mid: Suggests client caching. Senior: Explains Service Worker lifecycle, cache invalidation strategies, and edge-origin coordination for offline freshness.
⚠️Common Wrong Answer
No offline support - leads to poor UX for mobile users with flaky connectivity.
Step 5
Handling Sudden Traffic Spikes and Cache Invalidation
How would you design the system to gracefully handle sudden traffic spikes and propagate content invalidation efficiently?
💡 Hint
Consider cache pre-warming, rate limiting, and distributed invalidation protocols.
Key Decision
Use Kafka for cache invalidation event streaming across PoPs, combined with proactive cache pre-warming via origin push and rate limiting at edge nodes to protect origin during spikes.
Interviewer Expectation
Mid: Mentions cache invalidation and rate limiting. Senior: Details Kafka topic partitioning for invalidation, pre-warming triggers, and backpressure mechanisms at edge.
⚠️Common Wrong Answer
Synchronous invalidation calls - causes cascading failures and origin overload during spikes.
🔌
API Design Challenge
Sketch 3 core API endpoints for the CDN system: how clients request content, how edge nodes communicate cache status with origin, and how content invalidation is triggered.
Hints
  • How does the client request content and handle cache misses?
  • What mechanism do edge nodes use to report cache health or request updates from origin?
  • How is content invalidation or purge propagated across PoPs and edge nodes?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Multi-tier PoP and edge node hierarchy for global low latency
  • Hybrid origin pull and push content delivery strategy
  • TLS termination at edge with certificate automation
  • Offline content support for mobile users
  • Distributed cache invalidation mechanism
Good to Have - 30%
  • Proactive cache pre-warming to reduce cold start latency
  • Rate limiting and backpressure at edge nodes
  • Use of hardware TLS acceleration to meet latency SLAs
Bonus - 10%
  • Detailed API design for client requests, cache status reporting, and invalidation
  • Consideration of cost trade-offs between origin bandwidth and cache storage
Anti-patterns to Avoid
Single global cache layer causing high latency for distant users and creating a single point of failure
Origin-only TLS termination increasing latency and origin load, leading to poor user experience and scalability issues
Synchronous cache invalidation calls causing cascading failures and origin overload during traffic spikes
No offline support leading to poor mobile user experience due to inability to access content with flaky connectivity
Only origin pull strategy causing origin overload and high latency during traffic spikes due to cache cold starts
✅
Model Answer
▼ Reveal

A multi-tier CDN architecture with regional edge caches and local edge nodes ensures global low latency and failure isolation. A hybrid origin pull and push strategy balances freshness and bandwidth costs. TLS termination is performed at edge nodes using AWS Certificate Manager with automated rotation and hardware TLS acceleration to meet latency SLAs. Offline content availability is supported via client-side caching with Service Workers and IndexedDB, coordinated with edge cache hints. Kafka-based distributed cache invalidation streams enable scalable and efficient content purge propagation. Proactive cache pre-warming and rate limiting at edge nodes protect the origin during sudden traffic spikes.

Key Decisions
  • Adopt a multi-tier PoP hierarchy with local edge nodes and regional edge caches to reduce latency and isolate failures
  • Use a hybrid origin pull and push content delivery strategy: origin pull for dynamic/less popular content, origin push for popular static content pre-warming
  • Terminate TLS at edge nodes with AWS Certificate Manager and automate certificate rotation; use TLS 1.3 with hardware acceleration to minimize handshake latency
  • Implement client-side offline caching with Service Workers and IndexedDB, coordinated with edge cache hints via HTTP Cache-Control and background sync APIs
  • Use Kafka for asynchronous distributed cache invalidation event streaming across PoPs to avoid synchronous calls and cascading failures
  • Pre-warm caches proactively via origin push to reduce cold start latency during traffic spikes
  • Apply rate limiting and backpressure at edge nodes to protect origin servers from overload during sudden traffic surges
  • Multi-tier PoP architecture with AWS CloudFront Regional Edge Caches to reduce latency and isolate failures
  • Hybrid origin pull and push strategy balancing freshness, bandwidth cost, and cache storage
  • TLS termination at edge nodes using AWS Certificate Manager and hardware TLS acceleration for low latency
  • Client-side offline caching using Service Workers and IndexedDB for mobile users with intermittent connectivity
  • Kafka-based distributed cache invalidation event streaming for efficient and scalable content purge propagation
  • Proactive cache pre-warming via origin push to reduce cold start latency during traffic spikes
  • Rate limiting and backpressure at edge nodes to protect origin from overload during sudden traffic surges
  • HTTP Cache-Control headers and background sync APIs to coordinate cache freshness between edge and clients

Practice

(1/5)
1. A system must handle 1 million events per second, ensuring durability and ordered processing per aggregate. Which component best fits this requirement?
easy
A. Use a Redis pub/sub channel for event distribution
B. Use Kafka with partitioning by aggregate ID
C. Use a relational database with triggers for event handling
D. Use RabbitMQ with round-robin queue distribution

Solution

  1. Step 1: Identify Kafka's role in event sourcing

    Kafka supports high throughput with partitioning by aggregate ID, ensuring ordered event processing per aggregate.

  2. Step 2: Evaluate other options

    Redis pub/sub lacks durability guarantees; relational DB triggers don't scale to 1M events/sec; RabbitMQ's round-robin breaks ordering per aggregate.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka partitions by aggregate ID -> ordered, durable event stream [check]
Hint: Kafka partitions preserve order per aggregate [check]
Common Mistakes:
2. For a globally distributed key-value store requiring low write latency and strong consistency, which replication approach is best and why?
medium
A. Single-leader replication with leader in primary region only
B. Asynchronous replication with conflict resolution on reads
C. Synchronous replication with majority quorum writes to all regions
D. Synchronous replication with local quorum writes per region and global reconciliation

Solution

  1. Step 1: Evaluate latency and consistency trade-offs

    Global synchronous quorum to all regions (A) causes high latency; asynchronous (B) sacrifices strong consistency.

  2. Step 2: Consider local quorum with global reconciliation

    Local quorum writes reduce latency while global reconciliation maintains strong consistency.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Local quorum + global reconciliation balances latency and consistency [check]
Hint: Local quorum writes reduce latency, global reconciliation ensures consistency [check]
Common Mistakes:
3. Without the global CDN's cache invalidation mechanism, what exact failure occurs when a new video version is published?
medium
A. Users immediately see the new version but with degraded quality
B. Video streaming stops completely until manual cache reset
C. Some users continue to receive stale video chunks causing playback errors
D. The origin server crashes due to excessive cache refresh requests

Solution

  1. Step 1: Understand cache invalidation role

    Cache invalidation ensures edge caches update stale content after new video versions publish.

  2. Step 2: Trace failure without invalidation

    Without invalidation, edge caches keep serving stale content (Some users continue to receive stale video chunks causing playback errors), but more critically, clients request fresh content repeatedly, causing origin overload (The origin server crashes due to excessive cache refresh requests). Immediate degraded quality (Users immediately see the new version but with degraded quality) or complete stop (Video streaming stops completely until manual cache reset) do not occur.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Origin overload from repeated cache misses crashes server [check]
Hint: No invalidation -> origin overload from repeated cache misses [check]
Common Mistakes:
4. If the gRPC server's message queue is removed, what exactly breaks in the message delivery flow?
medium
A. Clients receive duplicate messages due to lack of deduplication
B. The server blocks sending until the client acknowledges, causing backpressure
C. Messages are lost if the client is slow or disconnected, with no retry mechanism
D. The server switches to synchronous unary calls, increasing latency

Solution

  1. Step 1: Role of message queue in gRPC server

    The queue buffers messages for slow or disconnected clients, enabling retries and flow control.

  2. Step 2: Effect of removing the queue

    Without the queue, messages sent to slow/disconnected clients are dropped immediately, causing message loss without retries.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    No queue -> message loss on slow/disconnected clients [check]
Hint: No queue -> messages lost if client slow or disconnected [check]
Common Mistakes:
5. At 10x scale, which component in a sharded CRDT distributed counter system is most likely to fail first and why?
hard
A. The shard replicas, because network partitions cause permanent state divergence without reconciliation
B. The replication layer, because increased shard count causes exponential message overhead saturating network bandwidth
C. The global aggregator node, because it becomes a bottleneck merging all shard states synchronously
D. The client-side counters, because local state grows unbounded without periodic compaction

Solution

  1. Step 1: Analyze scale impact on components

    Global aggregator (A) merges asynchronously, so less likely bottleneck. Replication overhead (C) grows but can be optimized. Client counters (D) can compact state.

  2. Step 2: Identify shard replicas failure mode

    At 10x scale, network partitions increase, causing shards to diverge permanently without reconciliation, breaking eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Network partitions cause shard divergence first at scale [check]
Hint: Network partitions cause shard divergence before aggregator bottlenecks [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