Practice a Cache Invalidation Decision With Stale Permissions

TL;DR

• In this fictional cache exercise, permission revocation is the requirement that determines acceptable stale access.
• Separate cached content from authorization and trace the stale-allow timeline across layers.
• Compare designs and authority-failure behavior against the actual guarantee, then test races and observable results.

Make revocation the central requirement

Practice this fictional design prompt: an application caches whether a user may download a project file. An administrator removes the user's access, but a later request still succeeds because a cached allow decision remains fresh. Explain the failure and choose a design that fits the required revocation behavior.

Start by asking how quickly revocation must take effect and which operations are sensitive. A stale product description and a stale authorization decision have different consequences. Do not choose a cache lifetime solely from a performance target before defining the acceptable authorization window.

Separate the cached object from the permission decision

A file's content may be cached while access is checked separately. Conversely, caching the whole authorized response can reuse both data and the decision that it was once allowed. Identify which layer is involved: application memory, shared cache, browser, CDN or a signed download URL.

RFC 9111 defines HTTP cache behavior and distinguishes directives such as private, no-cache and no-store. Those headers do not automatically solve an application-level permission cache. Explain the layer where each control applies instead of treating one header as universal revocation.

For the exercise, assume a server-side cache stores an allow decision keyed by user and project. The file content itself can remain in object storage; the question is whether a new request is authorized now.

Trace the stale-allow timeline

Write the sequence before proposing a fix:

The failure is not that caching exists. It is that the design's freshness guarantee does not meet the revocation requirement. A short expiration bounds some staleness but does not make revocation immediate. Event-driven invalidation can reduce delay but needs a plan for missed or delayed events.

Compare designs against the required guarantee

One option is to check the authoritative permission store for every sensitive request. That adds dependency and latency considerations, but it may be appropriate when stale allows are unacceptable. Another option is a versioned authorization model where a cached decision is accepted only against a current permission version; obtaining that current version is itself part of the consistency design.

A short-lived cache plus reliable invalidation may fit a system that explicitly permits a bounded revocation delay. State the bound and the failure behavior. Do not claim a TTL guarantees a particular delay if other layers can extend or independently preserve access.

Our system design frameworks guide can help you compare these options against requirements. The strongest answer names the consistency property rather than merely preferring the fastest design.

Define behavior when the authority is unavailable

If the permission store cannot be reached, decide whether the operation is denied, delayed or allowed from cached evidence under a documented policy. That choice depends on the operation and threat model. Do not accidentally fail open because a broad exception handler treats an unavailable check as success.

Also examine already issued capabilities. A signed URL may remain usable until its own expiration unless the storage or application design provides another revocation mechanism. Denying new URL issuance does not necessarily revoke links already issued. Explain that boundary if the prompt includes direct downloads.

A user who already downloaded a file possesses a copy; server-side revocation cannot make that copy disappear. Keep the guarantee focused on future authorized access rather than promising control over information already delivered.

Consider long-lived sessions separately from per-request checks. A WebSocket connection or background task may have been authorized once and continue acting after a permission change. Decide whether it must recheck, receive a revocation signal or terminate under the policy. Listing these paths prevents the answer from securing the download endpoint while leaving another route governed by an older decision.

For diagnosis, record the permission version or decision source used, without logging sensitive file contents. That evidence can distinguish a stale decision from an unrelated access-control defect.

Test races and observable outcomes

Create test cases for access before revocation, immediately after revocation, after cache expiry and during invalidation failure. Include a permission grant as well as a revoke; stale denial affects availability even though stale allow may be the more sensitive failure.

For concurrent requests, define the point at which revocation becomes effective in your model. A request authorized before the change may complete afterward, depending on the contract. If stricter behavior is required, explain the additional coordination rather than pretending there is no race.

Use the mock interview strategy guide to retry the scenario with a low-risk preference cache. The different answer should follow from different consequences. A strong permissions-cache explanation identifies every access path, states the revocation guarantee and chooses freshness and failure behavior that actually satisfy it.