Architecture scenarioHard~12 minHTTP API Semantics / 5 of 11

Interview question

How would you design Cache-Control headers for API responses that range from public reference data to sensitive user-specific data?

Design Cache-Control for API responses

Chooses response cache directives for public, private, sensitive, and revalidated API data without leaking user-specific content.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I start by deciding whether any cache may store the response and for how long it stays fresh. public permits shared caching, private limits reuse to a private cache, max-age defines freshness, and no-store says not to store the response. no-cache does not mean no storage; it means the stored response must be validated before reuse. Sensitive account or token responses normally use no-store, while stable public reference data can use a positive freshness lifetime.

Full answer below

Practice focus

Cache-Control, public, private, no-store, no-cache, max-age, shared caches, Vary, authorization, validation, and invalidation.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
HTTP caching can remove latency and origin load without application cache code, but the wrong directive can expose one user's response to another. The policy belongs to each representation's sensitivity and freshness contract.
I start by deciding whether any cache may store the response and for how long it stays fresh. public permits shared caching, private limits reuse to a private cache, max-age defines freshness, and no-store says not to store the response. no-cache does not mean no storage; it means the stored response must be validated before reuse. Sensitive account or token responses normally use no-store, while stable public reference data can use a positive freshness lifetime.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I account for every request value that changes the representation. If language, encoding, or origin changes the response, the corresponding Vary fields keep cache keys honest. Authorization and cookies make shared caching especially sensitive, so I do not mark authenticated personalized data public unless the contract and cache key are deliberately designed for it. For mutable public data, a short max-age plus ETag revalidation often gives a better balance than either permanent caching or no caching at all.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate browser, CDN, gateway, and application-cache behavior because each layer can have a different policy and purge mechanism. I document who owns invalidation, use surrogate controls only when the intermediary supports them, and test responses through the actual edge path. Cache directives must remain correct on errors, redirects, and authorization failures as well as 200 responses. I also define whether stale content may be served during revalidation or origin failure, because that availability trade-off must be explicit rather than an intermediary surprise. I monitor hit ratio, age, revalidation, stale serves, and accidental personalization signals, and I keep a rapid purge path for security or correctness incidents.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating no-cache as an instruction that nothing may be stored.
Marking authenticated personalized responses public for performance.
Adding max-age without defining invalidation or acceptable staleness.
Forgetting Vary when request headers select different representations.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The team cannot say whether a response may enter a shared cache.
A CDN policy overrides application headers without contract tests.
Sensitive responses can be recovered from browser or intermediary storage.
Cache incidents have no purge or verification procedure.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What is the difference between no-cache and no-store?
When would private be useful?
How do ETags complement a short freshness lifetime?

Continue the section

Next in HTTP API Semantics: ETag conditional GET

Step 6 of 11

ETag and If-None-Match conditional requests

Opening drill

Architecture scenarioHard~12 minHTTP API Semantics / 5 of 11

Interview question

How would you design Cache-Control headers for API responses that range from public reference data to sensitive user-specific data?

Design Cache-Control for API responses

Chooses response cache directives for public, private, sensitive, and revalidated API data without leaking user-specific content.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Cache-Control, public, private, no-store, no-cache, max-age, shared caches, Vary, authorization, validation, and invalidation.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
HTTP caching can remove latency and origin load without application cache code, but the wrong directive can expose one user's response to another. The policy belongs to each representation's sensitivity and freshness contract.
I start by deciding whether any cache may store the response and for how long it stays fresh. public permits shared caching, private limits reuse to a private cache, max-age defines freshness, and no-store says not to store the response. no-cache does not mean no storage; it means the stored response must be validated before reuse. Sensitive account or token responses normally use no-store, while stable public reference data can use a positive freshness lifetime.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I account for every request value that changes the representation. If language, encoding, or origin changes the response, the corresponding Vary fields keep cache keys honest. Authorization and cookies make shared caching especially sensitive, so I do not mark authenticated personalized data public unless the contract and cache key are deliberately designed for it. For mutable public data, a short max-age plus ETag revalidation often gives a better balance than either permanent caching or no caching at all.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate browser, CDN, gateway, and application-cache behavior because each layer can have a different policy and purge mechanism. I document who owns invalidation, use surrogate controls only when the intermediary supports them, and test responses through the actual edge path. Cache directives must remain correct on errors, redirects, and authorization failures as well as 200 responses. I also define whether stale content may be served during revalidation or origin failure, because that availability trade-off must be explicit rather than an intermediary surprise. I monitor hit ratio, age, revalidation, stale serves, and accidental personalization signals, and I keep a rapid purge path for security or correctness incidents.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating no-cache as an instruction that nothing may be stored.
Marking authenticated personalized responses public for performance.
Adding max-age without defining invalidation or acceptable staleness.
Forgetting Vary when request headers select different representations.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The team cannot say whether a response may enter a shared cache.
A CDN policy overrides application headers without contract tests.
Sensitive responses can be recovered from browser or intermediary storage.
Cache incidents have no purge or verification procedure.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What is the difference between no-cache and no-store?
When would private be useful?
How do ETags complement a short freshness lifetime?

Continue the section

Next in HTTP API Semantics: ETag conditional GET

Step 6 of 11

ETag and If-None-Match conditional requests

How would you design Cache-Control headers for API responses that range from public reference data to sensitive user-specific data?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you design Cache-Control headers for API responses that range from public reference data to sensitive user-specific data?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section