CDNs System Design Interview: Edge Caching Reasoning

The CDN question in a system design interview is rarely asking for a definition. It is asking whether you can connect a component to a requirement, say what it costs you, and name what breaks. Handling CDNs in a system design interview well means doing that in about a minute, then moving on.

This guide is about how to reason about CDNs out loud: where they sit in the request path, what belongs at the edge, how cache keys and invalidation work, and which trade-offs to state plainly. It is written for engineering candidates preparing for system design interviews, including career changers moving into engineering.

Start With the Problem a CDN Solves, Not the Acronym

Open with the user-facing problem, because that is what the interviewer is grading.

Three problems tend to come up together:

Latency for distant users. A user far from your origin server waits longer for every round trip, and a page needs many of them.
Origin load. If every request reaches your application servers, you pay for compute and database work you did not need to do.
Bandwidth cost. Serving large static files repeatedly from origin is expensive in both money and capacity.

The one-sentence version: a CDN is a distributed layer of cache servers that serves content from a location closer to the user.

Say it like that, then immediately tie it to the scenario. For example: "You said the product page needs to feel fast for users across three regions, so I would put a CDN in front of the static assets and the public catalogue response."

Why interviewers care: they are testing whether you can attach a component to a stated requirement. A memorised definition with no requirement behind it sounds like recitation.

A concrete example helps. Picture a product page that loads images, a CSS file, a JavaScript bundle, and a public API response listing categories. Many users request those identically. That identical-ness is what makes them good candidates for the edge.

One honesty point before you continue. If you have not operated a CDN, say so. "I have not run one in production, so I would reason from first principles here" is a stronger answer than inventing operational detail you cannot defend when the interviewer asks a follow-up.

A 60-Second CDN Explanation You Can Actually Say Out Loud

You want a short, structured answer you can deliver without rambling, because the CDN is one component in a 45-minute design, not the whole conversation.

Structure it in four beats:

What it is. A distributed set of cache servers that hold copies of content nearer the user.
Where it sits. Between the client and your origin, in the request path.
What it caches. Static assets, and public responses that many users request identically.
What it does not do. It is not a database, not a queue, and not a replacement for application-level caching.

Then walk the request path in one breath:

The client requests an asset. If the edge has a fresh copy, it returns it directly. If not, the edge fetches from origin, returns the response, and keeps a copy for the next user who asks for the same thing.

That is the whole mechanism. The interesting part is deciding what you are willing to serve from a copy.

Practise saying this in under a minute. Time yourself. If it runs long, cut the mechanism first and keep the requirement link, because the requirement link is what earns the mark.

What to Cache, and What to Keep Out of the Edge

This is where a candidate either sounds thoughtful or sounds like they would ship an incident.

Easy yes:

Images, fonts, CSS and JavaScript bundles.
Versioned build artefacts, which change only on deploy.

Reasonable yes, with care:

Public, non-personalised API responses: product catalogues, public feeds, reference data such as country lists or currency tables.
Anything where every user gets the same bytes and a slightly older copy is acceptable.

No, and say why:

Authenticated or per-user responses. A cached response keyed only by URL can be handed to the wrong user. That is a correctness and privacy problem, not a performance one.
Tokens, personal records, and anything with a short privacy shelf life. These should not sit in shared caches at all.

Tie each decision back to a requirement you stated earlier. If you said "reads can be eventually consistent," the catalogue is a yes. If you said "the account balance must be current," it is a no, and you can say so in one clause.

Cache Keys, TTLs and Invalidation: The Part Interviewers Probe

Definitions are easy. This section is where strong candidates separate themselves, so slow down here.

The cache key is the identity of the object

The cache key is what the edge uses to decide whether two requests want the same thing. It typically includes the URL and the query string. It may include selected headers, such as an encoding variant. It should deliberately exclude anything that would fragment the cache into uselessness, like a random request ID.

Say the consequence: "If I include a header that varies per user, my hit rate collapses and I have added a hop for nothing."

TTL is a trade-off, not a number

Time-to-live controls how long a copy stays fresh. A long TTL means fewer origin requests and a higher chance of serving something stale. A short TTL means fresher content and more origin traffic.

Do not invent a specific number unless you can justify it. Better: "For hashed asset filenames I would use a long TTL, because the name changes when the content changes. For the catalogue response I would use a short TTL, because freshness matters more to me than origin load there."

Invalidation is the hard part

Three strategies worth naming:

Versioned filenames. Change the file name when the content changes, so the old copy simply stops being requested.
Purge on deploy. Explicitly remove cached objects as part of the release process.
Short TTLs for volatile data. Let staleness expire on its own where a purge is not worth the complexity.

Then name the failure mode before the interviewer does: stale content served after an update. Users see an old price, an old banner, or a bug you already fixed. Detection usually means comparing what the edge serves against what origin holds, and watching for a drop in purge latency or an unexpected rise in stale-content reports.

Ending this section with "invalidation is the part I would spend the most design time on" signals that you know where the risk lives.

Trade-Offs to Name Out Loud

Interviewers listen for whether you can hold two costs in your head at once. Name them in pairs.

Cost. Edge bandwidth and request pricing against origin egress and compute. Offloading traffic is not free; it moves where you pay.
Complexity. Another moving part in the request path, and another place to debug when something is slow or wrong.
Consistency. Stronger caching means staler reads. Weaker caching means more origin traffic. You are choosing a point on that line.
Operational surface. Cache-hit ratio, purge latency, and behaviour that differs by region.

The sentence that lands it: "I would cache this because the catalogue is public and identical for everyone, and I accept that some users briefly see a slightly older version as the cost."

Say "because" at least once per decision. It is the cheapest way to show reasoning rather than preference. For a worked example of the same reasoning applied to another component, see Rate Limiter System Design Interview: Reasoning Out Loud.

How a CDN Fits Into a Full Design Answer

Placement matters more than depth here.

Put the CDN in after you have stated functional and non-functional requirements, not before. If you reach for it first, it looks like a habit rather than a decision.

A small flow is enough:

Client requests a page or asset.
Edge serves a cached copy if it has a fresh one.
On a miss, the edge asks origin.
Origin may hit the database or another service, then responds.
The edge stores the response for the next identical request.

Then answer three what-ifs, briefly:

On a cache miss: the first user pays the extra hop; everyone after them does not.
On a purge: requests fall through to origin until the cache refills, so a purge during peak traffic is a load event, not just a content change.
During an origin outage: the edge can keep serving fresh cached copies, which is a real availability benefit, but only for content that was cached and has not expired.

Keep the diagram small. Interviewers care about the reasoning, not the artwork, and a clean five-box sketch you can talk over beats a detailed one you have to apologise for.

Common Mistakes and How to Avoid Them

Reciting a definition with no scenario. Fix: attach it to a requirement in the same sentence.
Caching everything. Fix: separate static, public and per-user responses out loud before you decide.
Ignoring invalidation. Fix: name the stale-content failure mode and one detection method.
Over-claiming operational experience. Fix: say what you have actually done, then reason from first principles.
Forgetting monitoring. Fix: mention cache-hit ratio and purge latency as the two things you would watch after launch.

Practising the CDN Answer Honestly

Preparation here is repetition with feedback, not memorising a script.

Try this sequence:

Rehearse the 60-second explanation until it is smooth.
Rehearse the trade-off sentence: "I would cache this because X, and accept Y."
Rehearse the failure mode: stale content after an update, and how you would notice.
Record yourself and check whether you said "because" at least once per decision.
Use your own project, or a public system you genuinely understand, as the example, so the detail is real.

If you use a practice tool, keep it to preparation and review. The interview itself is your own work, and the honest version of your reasoning is more convincing than a polished answer you cannot defend. When you review, write down one thing to say more clearly next time. That single note is usually worth more than another hour of reading.

If you are working through other components too, our blog has walkthroughs that use the same requirements-first approach, including Python Interview Questions: Concepts and Trade-Offs for the coding side of the loop.

Before You Walk In

The CDN is a small component that reveals a lot: whether you can connect a tool to a requirement, name what it costs, and describe what breaks. Say the problem first, give the one-minute explanation, decide what belongs at the edge, then spend your real time on cache keys and invalidation. Finish with one trade-off sentence and one monitoring signal, and move on to the next part of the design.

Frequently asked questions

Do I need to know how a specific CDN provider works to answer this in an interview?

No. Interviewers are testing the reasoning, not vendor knowledge. Explain what the CDN does in the request path, what you would cache, how the cache key and TTL work, and how you would invalidate. Naming a provider adds little unless the scenario has a constraint that depends on one.

How deep should you go on cache invalidation in a CDNs system design interview?

Enough to show you know it is the risky part. Name one strategy you would use, such as versioned filenames or purge on deploy, state the failure mode of stale content after an update, and say how you would detect it. A few sentences is usually right; a long detour costs you time elsewhere.

Is it ever wrong to put a CDN in front of an API?

It is wrong when the responses are per-user or sensitive, because a shared cache keyed only by URL can serve one user's data to another. It is reasonable for public, non-personalised responses that many users request identically, where a slightly older copy is acceptable.

What is the difference between a CDN and an application-level cache?

A CDN caches responses near the user, outside your application, and reduces latency and origin traffic for content that is shared. An application-level cache sits inside or beside your service and typically holds computed results, database query results or session data. They solve overlapping but different problems, and you can use both.

How do I explain a CDN if I have never used one at work?

Say plainly that you have not operated one, then reason from the problem: distant users wait longer, origin does repeated work, and identical requests are wasteful. Describe the request path, what you would cache, and the trade-offs you would accept. Honest reasoning from first principles is a legitimate answer.

Should I mention CDN cost in a system design interview?

Yes, briefly. Cost is a real trade-off: offloading traffic to the edge moves where you pay rather than removing the bill. One sentence linking cost to a requirement is enough, unless the interviewer asks you to go deeper.

Practise your CDN explanation out loud and review it.