Global CDN
Serve globally cached objects while propagating invalidations with a defined freshness objective and observable exceptions.
Serve globally cached objects while propagating invalidations with a defined freshness objective and observable exceptions. This worked design targets SDE-3; the scale figures below are exercise assumptions, not claims about a named company's implementation.
Clarify the prompt
| Ask the interviewer | Decision to record |
|---|---|
| Immutable assets or mutable/private content? | Cacheability and invalidation differ. |
| Does seconds mean a p99 objective or an absolute bound during partitions? | Disconnected edges cannot receive new invalidations. |
| What are cache-key dimensions and origin protection limits? | Authentication must not leak through shared caches. |
Requirements and scope
The core deliverable is: Serve globally cached objects while propagating invalidations with a defined freshness objective and observable exceptions. The first design implements the APIs below and the state constraints in the data model. Agree the latency, freshness, retention and failure policy before adding infrastructure. Every successful acknowledgment must have an explicit meaning: accepted intent, committed state or completed external work. These are separate milestones.
Capacity and bottleneck reasoning
Assume one million edge requests/s averaging 100 KB: 100 GB/s delivery. At 95% byte hit ratio the origin still serves about 5 GB/s. Ten thousand invalidations/s across 200 points of presence require hierarchical fanout and batching.
Keep average and peak demand separate. Add replication, indexes, retries and safety headroom to raw arithmetic before selecting capacity. Load-test the busiest ownership key and recovery traffic as well as uniform happy-path throughput.
APIs and data model
- GET /assets/{contentHash} -> immutable bytes
- GET /content/{id} -> policy-controlled cached representation
- POST /purges {scope,requestKey} -> generation and propagation status
cache_entry(cache_key,version,expires_at,etag,body_ref)
invalidation(object_or_tag,generation,event_id,issued_at)
edge_checkpoint(edge_id,last_generation,last_seen); origin_version(object_id,current_generation)Authorize resource ownership at the API boundary; do not trust IDs or state supplied by a client. Bind retry identity to the caller and payload for mutating operations. Reject an incompatible replay instead of returning an unrelated stored result.
Component relationships
Read the diagram
Follow the labeled relationship panels; they are separate directed paths, not one global timeline.
Step-by-step design
1. Establish the authority
Route to a healthy nearby edge and use a normalized key including every representation dimension. Collapse simultaneous misses and use origin shields, stale-serving policy and quotas to prevent a global cold-cache stampede.
2. Make retries and concurrent work safe
Publish immutable content under a versioned URL whenever possible. For mutable names, commit the new origin generation and publish a durable invalidation event. Edges remember the latest generation and reject stale fills that began before the purge.
3. Scale and recover the critical path
Track acknowledgments and periodically reconcile missed generations. A disconnected edge must stop serving expired mutable content if the freshness contract requires it; availability and freshness cannot both be guaranteed across an arbitrary partition. Private responses need explicit authorization-aware cache policy.
Worked request and concurrency example
An edge begins fetching generation 7. The origin publishes generation 8 and purge P arrives before the fetch completes. The edge stores an invalidation watermark of 8; the late generation-7 response cannot repopulate the cache. If an edge misses P, its checkpoint lag exposes the gap and replay repairs it. Immutable hashed assets avoid this overwrite race by giving versions distinct keys.
Failure and recovery walkthrough
A purge control-plane partition leaves some edges unaware. TTL and revalidation bound normal stale serving, but a hard global seconds guarantee requires failing closed at edges that cannot prove freshness. Return propagation status rather than falsely reporting universal completion.
Read the diagram
This numbered trace follows one scenario; explain the durable evidence at each transition.
Decisions and alternatives
| Decision | Trade-off |
|---|---|
| Alternative 1 | Versioned URLs are easy to cache and roll back but require changing references. Tag-based purge supports mutable products at higher control-plane complexity. |
| Alternative 2 | Serving stale on origin failure improves availability for public media; revoked private content may require immediate refusal and a separate authorization path. |
Operational contract
Monitor byte hit ratio, origin egress, purge p50/p99 convergence and unreachable-edge count. Test reordered invalidations, a late fill, regional isolation and origin overload after mass purge.
Choose alert thresholds from the agreed user-facing objective. Assign an owner for stuck work and a replay/repair procedure that preserves the original business identity. Bound queue depth, concurrency and recovery throughput so an outage does not produce an uncontrolled catch-up burst.
Foundation, senior and staff depth
- Foundation: explain the user action, model, first complete request and the correctness constraint without relying on a list of technologies.
- Senior: defend this lesson's partition/coordination boundary, capacity estimate and failure recovery; explain the cost of the rejected alternative.
- Staff: identify failure domains and operational ownership, stage a rollout with measured guardrails, and state when rollback stops being safe.
Practice before revealing the answer
Spend 45 minutes: 5 clarifying scope, 7 on capacity/APIs/state, 12 on the first architecture, 15 on the concurrency and failure examples, and 6 on trade-offs and operations. Draw your own design before comparing it with this chapter.
Question: Why can a simple delete-from-cache operation fail during invalidation?
Show answer and explanation
Answer: A miss already in flight can refill the old value after the delete. Keep generation/tombstone watermarks and validate the fetched version before insertion, not just at purge receipt.
Verification and rollout
Reproduce the worked example using two concurrent actors or a repeated request where applicable. Inject the stated failure between the durable transition and its acknowledgment; verify the resulting state and user-visible outcome. For read/ML paths, test missing or stale dependencies and verify the documented fallback still enforces permissions. Use a small canary, compare correctness and user-facing latency with the baseline, and roll back when those guardrails regress. Do not use an average throughput number as evidence that a tail-latency target is met.
Primary technical reference
Official documentation for the mechanism used in this exercise. This lesson is an original interview design, not a description of undisclosed company internals.
Related study
Before this design, review these mechanisms and identify which owns the critical state transition:
Use the Interview Playbook to adapt the depth and timing, then return to the question breakdown overview.
Why can a simple delete-from-cache operation fail during invalidation?
Your design draft
Clarify assumptions, explain your approach, and test the difficult cases. Save your draft, then compare it with the study notes.
Self-review checklist
Self-guided practice. Automated AI feedback and code execution are not connected.