Problem and context
A page passes through browser, CDN, and origin reverse-proxy caches. Users report occasional slow requests, and you must use standardized response fields to identify which layer missed, revalidated, or collapsed requests. Design the plan with RFC 9211 and address privacy and cache-poisoning risks in production.
What the interviewer evaluates
The key is that Cache-Status is a structured-field list; each member represents a cache that handled the request, ordered from the cache nearest the origin to the cache nearest the user. Explain hit versus fwd, forwarding reasons and ttl, plus authorization and redaction for diagnostics.
Clarifying questions to ask first
Cache topology and ownership
Ask whether the browser appends the field, whether each layer preserves upstream values, and which teams can change CDN and reverse-proxy configuration. Without ordering, the list cannot be interpreted reliably.
Debug sampling and sensitive data
Ask whether diagnostics are enabled only for internal requests, the sampling rate, and log retention. Cache keys, tenant identifiers, and personalized responses may be sensitive and should not be returned to every client.
Freshness and consistency goals
Confirm Cache-Control, validators, tolerated stale windows, and business consistency requirements. A negative ttl means that layer calculated staleness; it does not alone prove stale bytes were served.
30-second answer framework
“Each cache appends its own Cache-Status member while preserving the list, which I read from origin toward the user. hit means no next hop was needed; fwd carries reasons such as uri-miss, vary-miss, or stale, and fwd-status=304 identifies revalidation. Only authorized internal debugging returns detail or key; production output is redacted to avoid tenant leakage and cache-poisoning clues.”
Detailed solution steps
Step 1: Parse the structured field
Parse Cache-Status as an RFC 8941 list and read each member's identifier and parameters. Do not use substring checks: members can contain quoted strings, reordered parameters, and repeated layers.
Step 2: Define append and ordering rules
When a layer sees an existing field, it appends its member rather than overwriting upstream evidence. The origin-nearest cache appears first and the user-nearest cache last; a missing layer is recorded as a topology gap, not guessed.
Step 3: Interpret hits and forwarding
hit means the layer satisfied the request from stored data. fwd=uri-miss means no matching URI, vary-miss means Vary selection failed, and stale means the selected response was stale. fwd-status is meaningful on forwarding and distinguishes a 304 validation from another response.
Step 4: Correlate TTL, storage, and collapse
ttl is the layer's remaining freshness estimate and can be negative; stored says whether a forwarded response was stored; collapsed says whether requests shared one forward. Correlate these fields with request IDs, origin time, and status codes to explain tail latency.
Step 5: Handle personalization and cache keys
For authenticated, tenant-specific, or cookie-bearing responses, first verify RFC 9111 cacheability. Production responses expose only cache identity, hit type, and coarse TTL; key and detail stay on a controlled debug channel with user-controlled fragments removed.
Step 6: Build a safe sampling policy
Enable diagnostics with an internal request field, short-lived authorization, or edge configuration, and keep detailed output off the public path by default. Parse and protect logs so attackers cannot infer timing behavior or discover cache keys.
Step 7: Verify end to end
Create URI-miss, Vary-miss, stale-validation, request-collapse, and multi-layer-hit cases. Check list order, fwd-status, TTL sign, and preservation of upstream members. Compare responses, cache logs, and origin traces to ensure observability does not change caching semantics.
High-quality sample answer
I would have browser, CDN, and reverse proxy append Cache-Status and parse it with a structured-field parser. I would first classify each layer as hit or fwd, then use forwarding reason, fwd-status, ttl, stored, and collapsed to explain slow requests. Only internal debugging would expose key or detail; public responses stay redacted. Tests cover URI miss, Vary miss, stale 304, request collapse, and multi-layer ordering.
Common mistakes
- Mistake: Treating the last member as the only result. → Why: The list records the whole cache chain. → Fix: Explain every member from origin to user.
- Mistake: Assuming hit always means fresh. → Why: A stale response can be served by an explicit local policy. → Fix: Combine ttl with Cache-Control and forwarding state.
- Mistake: Overwriting upstream Cache-Status. → Why: Earlier evidence is lost. → Fix: Preserve and append a member.
- Mistake: Returning key and detail publicly. → Why: They can reveal tenant, timing, or poisoning clues. → Fix: Restrict and redact a debug channel.
Follow-up questions and answers
Follow-up 1: How do hit and 304 validation relate?
Reuse without contacting the next hop is a hit. If the cache must validate with the next hop, it uses fwd; fwd-status=304 can show that the next hop validated the stored representation.
Follow-up 2: Can multiple Cache-Status field lines be concatenated directly?
HTTP field combination treats same-name fields as one list, but implementations should use an RFC 8941 parser for commas, quotes, and parameters rather than simple string concatenation.
Follow-up 3: Does a negative TTL prove stale bytes reached the user?
No. It says that layer calculated the response as stale. The layer may revalidate or serve it under an explicitly permitted stale policy; inspect forwarding and response directives.
Follow-up 4: How do you debug slowness affecting only some users?
Compare members, Vary selection, TTL, and collapsed rates across nodes, then correlate geography, cookies, and request fields. A vary-miss isolated to one layer suggests key-construction drift or configuration skew.