03Building blocksContent Delivery Networks (CDN)
03 · Building block
Content Delivery Networks (CDN)
Move cacheable content to the edge and reason about origins, invalidation, regional latency, and signed access.Architecture map
See where the component sits in a real system.
Write
Global users enters through Edge PoP. Purge/config API owns validation and commits the durable record to Origin/object store.
Propagate
Invalidation bus separates the committed write from background work. PoP cache agents can retry safely while it builds Regional origin shield.
Read
Edge cache lookup serves from Regional origin shield, then checks authoritative state whenever freshness, policy, or correctness requires it. It also consults Edge cache fleet as an explicit dependency.
Say this first: Edges serve versioned cacheable objects; shield and origin remain the repair path for misses and invalidations.
Open the full whiteboard ↗Explain every boundary before adding more boxes.
Edges serve versioned cacheable objects; shield and origin remain the repair path for misses and invalidations.
Move cacheable content to the edge and reason about origins, invalidation, regional latency, and signed access.
Hit ratio · origin offload · TTFB · purge time · stale serves · egress cost. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.
End-to-end walkthrough
Trace the architecture in this order.
- 01
Enter and classify the request
Global users → Edge PoPStatic/media requests enters over HTTPS. Edge PoP handles identity, admission, routing, and request context; it deliberately does not own domain truth.
- 02
Validate, then cross the commit boundary
Edge PoP → Purge/config API → Origin/object storePurge/config API receives the command, checks invariants and retry identity, then uses commit to update Origin/object store. The user-visible mutation is accepted only after this boundary succeeds.
- 03
Move replayable work off the request path
Purge/config API → Invalidation bus → PoP cache agents → Regional origin shieldPurge/config API emits publish after commit; PoP cache agents uses consume and purge version to build Regional origin shield. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
- 04
Serve reads from the right authority
Edge PoP → Edge cache lookup → Regional origin shield / Origin/object storeEdge cache lookup uses optimized read for the common, read-optimized path and origin fetch when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
- 05
Contain the dependency boundary
Edge cache lookup → Edge cache fleetcache hit crosses into Edge cache fleet. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.
Ownership ledger
Why each box exists—and what it must defend.
| Component | Owns | Why it exists | Interviewer probe |
|---|---|---|---|
| Edge PoPTLS + cache key + policy | Identity, admission, routing | Protects the system edge and attaches trusted context before domain work begins. | Timeout budgets, quotas, regional routing |
| Purge/config APIVersioned invalidation | Write invariants and retry identity | Serializes or conditionally applies state changes before acknowledging success. | Concurrent writes, deduplication, hot ownership |
| Origin/object storeAuthoritative content | Authoritative durable state | Provides the one record used to resolve disputes, recover, and rebuild projections. | Partition key, replication, consistency |
| Invalidation busPurge + config propagation | Durable asynchronous handoff | Absorbs bursts and lets slow or optional work retry independently of the request. | Ordering key, lag, retention, dead letters |
| PoP cache agentsApply purge + revalidate | Replayable processing | Runs expensive, fan-out, or side-effecting work with leases and bounded retries. | Idempotency, poison work, autoscaling |
| Regional origin shieldCollapse misses | Rebuildable query state | Shapes data for the dominant reads without weakening the write-side invariant. | Freshness, versioning, rebuild time |
| Edge cache lookupFresh, stale, or miss | Read composition and freshness policy | Chooses authoritative or derived state and returns a stable client contract. | Fan-out, cache policy, partial results |
| Edge cache fleetServe bytes near users | External capability, not local truth | Keeps a specialized or third-party concern behind a replaceable contract. | Ambiguous timeout, circuit breaking, fallback |
Physical design
Name the database, shard key, indexes, and guarantees.
- Database + storage
- Edge cache PoPs and regional shields serve bytes; object/application origins remain truth; a versioned control store distributes policy.
- Partitioning / sharding
- Route by anycast/DNS to PoP, then hash cache keys within the PoP. Shields partition by host/object to collapse origin misses.
- Indexes
- Normalized cache key, surrogate-key purge index, and immutable origin object key/version.
- Replication + consistency
- Freshness follows Cache-Control/ETag/purge version; private authorization is checked; stale serving is an explicit policy.
- Cache, queue + recovery
- Use immutable URLs, stale-while-revalidate, negative cache, request collapse, signed delivery, and versioned purge propagation.
- Capacity math
- Estimate RPS, hit ratio, bytes/sec, object sizes, PoP working set, origin offload, purge rate, and regional p99.
- Alternative rejected
- A regional cache protects origin but not global latency/egress; CDN is earned by distance and flash crowds.
Deep-dive candidates
Pick one risk and explain the mechanism, alternative, and cost.
Request path
DNS or anycast selects an edge; a hit returns locally, while a miss fetches through an origin shield and populates cache.
Tie the mechanism back to Origin/object store, Regional origin shield, and the stated hit ratio · origin offload · ttfb · purge time · stale serves · egress cost envelope.Cacheability
Static versioned assets are ideal. Personalized, private, or rapidly changing responses need careful keys and authorization.
Tie the mechanism back to Origin/object store, Regional origin shield, and the stated hit ratio · origin offload · ttfb · purge time · stale serves · egress cost envelope.Cache control
Use max-age, surrogate controls, stale-while-revalidate, ETag validation, and immutable versioned URLs to state freshness.
Tie the mechanism back to Origin/object store, Regional origin shield, and the stated hit ratio · origin offload · ttfb · purge time · stale serves · egress cost envelope.Failure pressure test
Show detection, containment, recovery, and evidence.
The topic-specific correctness risk
A missing cache-key dimension can leak personalized or unauthorized content.
Track failed promises at Origin/object store and Regional origin shield.Invalidation bus or PoP cache agents falls behind
Bound admission, scale on oldest-work age, retry with jitter, and isolate poison work before lag becomes unbounded.
Oldest event age · retry rate · dead-letter volume · projection freshnessOrigin/object store is slow or unavailable
Apply a deadline, preserve retry identity, fail over only within the stated consistency model, and reconcile any ambiguous result.
Commit p99 · timeout rate · replication lag · recovery time- Functional requirements and non-goals
- Peak traffic, storage, bandwidth, and growth
- Entities, APIs, idempotency, and pagination
- Source of truth and consistency promise
- Partition key, replicas, caches, and hot spots
- Retries, backpressure, failover, and reconciliation
- Latency, saturation, correctness, and recovery metrics
- Security, migration, cost, and multi-region evolution
Read the solid request path first, stop at the source of truth, then follow the dashed event path into workers and rebuildable read models. Every arrow names a contract you should be ready to defend.
- 01
Viewer — Requests content Define the output contract before moving to the next owner.
- 02
Edge POP — Evaluates cache policy Define the output contract before moving to the next owner.
- 03
Shield — Collapses regional misses Define the output contract before moving to the next owner.
- 04
Origin — Returns canonical bytes Define the output contract before moving to the next owner.
- 05
Purge system — Invalidates versions Define the output contract before moving to the next owner.
- 06
Telemetry — Measures offload Confirm the result and emit the evidence needed to reconcile it.
Lesson spine
What you need to understand.
A CDN moves reusable bytes and some computation closer to users while shielding the origin from distance and spikes.
Request path
DNS or anycast selects an edge; a hit returns locally, while a miss fetches through an origin shield and populates cache.
Cacheability
Static versioned assets are ideal. Personalized, private, or rapidly changing responses need careful keys and authorization.
Cache control
Use max-age, surrogate controls, stale-while-revalidate, ETag validation, and immutable versioned URLs to state freshness.
Invalidation
Prefer cache busting by version. Use targeted purges for urgent correction and short TTLs when staleness is naturally bounded.
Signed delivery
Protect private media with scoped, expiring tokens that the edge can validate without exposing the origin.
Measure the promise
Watch hit ratio, origin offload, time to first byte, edge errors, and regional tail latency.
Before the boxes
Frame the decision.
What must work
Move cacheable content to the edge and reason about origins, invalidation, regional latency, and signed access.
What changes the design
Hit ratio · origin offload · TTFB · purge time · stale serves · egress cost
What owns the truth
Identify the component that commits authoritative state, then separate synchronous confirmation from derived work.
What stays simple
Do not add global coordination, multi-region writes, or a specialized store until a requirement earns the complexity.
Decision table
Make the trade-offs explicit.
| Decision | Defensible position | Cost to acknowledge |
|---|---|---|
| Primary mechanism | Versioned immutable URLs simplify invalidation; mutable URLs require purge or revalidation. | The stronger guarantee usually adds coordination, latency, state, or operational work. |
| Sync vs. async | Keep only correctness-critical confirmation synchronous. Move derived views, notifications, analytics, and cleanup behind a durable boundary. | Async work needs idempotency, lag monitoring, replay, and a product definition for partial completion. |
| Simple vs. scaled | Begin with one logical owner and a clear API. Partition or replicate only the resource proven to be the first bottleneck. | Migration requires stable identities, versioned contracts, backfill, and a rollback path. |
Failure review
Design the recovery path.
Topic-specific risk
A missing cache-key dimension can leak personalized or unauthorized content.
ResponsePersist enough identity and state to distinguish retry, resume, compensation, and operator repair.
Dependency timeout
A timeout is ambiguous: the remote side may have failed, succeeded, or still be running.
ResponseUse deadlines, bounded backoff with jitter, idempotency keys, and a status or reconciliation path.
Overload or skew
Average capacity can look healthy while a tenant, key, partition, region, or expensive request saturates one owner.
ResponseExpose queue depth and hot-key share, apply backpressure, isolate tenants, and degrade optional work before correctness.
Evidence + level bar
Prove the design can be operated.
Health of the promise
Measure user-visible latency or freshness, correctness drift, saturation, retry volume, and time to recover. Alert on the failed promise—not only CPU.
Complete and clear
Finish the happy path, identify the state owner, choose reasonable building blocks, and explain one scale mechanism.
Trade-offs and failure
Separate read and write paths, define consistency, explain partitioning, and make duplicate or partial failure safe.
Evolution and operations
Discuss multi-region boundaries, migration, tenant isolation, capacity, observability, and how the architecture changes over time.
Interview language
Open the deep dive with a claim.
“For Content Delivery Networks (CDN), the decision I want to make explicit is this: Versioned immutable URLs simplify invalidation; mutable URLs require purge or revalidation. I’ll trace the state-changing path first, show where the result becomes durable, then test the design against the highest-risk failure and our target scale.”
08 · Retrieval check
Can you defend it without the page?
- For Content Delivery Networks (CDN), where is the correctness boundary and which failure would you test first?
- Which component owns committed truth, and what event or response proves the commit?
- Where is the first scaling or coordination bottleneck under the stated envelope?
- What happens after an ambiguous timeout or duplicate operation?
- Which complexity would you remove at one hundredth of the scale?