Can you serve this cached issue?
The cache is fast. It is also one version behind the permission-sensitive update.
The question
Northline’s incident workspace has a search index, object cache and authoritative issue store. An authorized editor changed the issue from public to restricted. The viewer in this packet can read public issues only; the editor remains authorized to read restricted issues.
| Version | Visibility | |
|---|---|---|
| Authoritative issue | 42 | Restricted |
| Object cache | 41 | Public |
| Search index | 41 | Public |
Versions and visibility are authored. Search freshness and permission enforcement have separate contracts.
Search results may be 30 seconds old, but must not reveal restricted issue data to the viewer. The response must authorize the exact issue version served. Separately, the authorized editor must be able to read back its committed version.
“Choose the served version, authorization input and stale-event handling.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Separate discovery from disclosure
What would you do here? Open the move you’d make.
Apply the current object/permission contract before returning content.
The strong move. Search freshness does not override authorization.
Serve cached version 41 because it was public when indexed.
Tempting, but it misses something. The current version is restricted and the caller cannot read it.
See how a strong candidate says it
“A stale search index can identify a candidate result; it cannot authorize disclosing that result.”
Why it works: The packet permits stale search but prohibits restricted content exposure.
Step 2: Keep object and permission aligned
What would you do here? Open the move you’d make.
Authorize version 41 and return version 42 to improve freshness.
Tempting, but it misses something. The permission decision describes a different object state.
Use version 42 for the authorization and returned-data boundary.
The strong move. This caller is denied restricted content; no stale payload substitutes for it.
See how a strong candidate says it
“Evaluate permission against the same authoritative issue version that will be returned, then serve only if allowed.”
Why it works: A decision based on one version and a payload from another creates a race.
Step 3: Preserve read-after-write
What would you do here? Open the move you’d make.
Use a minimum committed version for this readback.
The strong move. The client’s required freshness is explicit.
Make all search reads strongly consistent to solve every case.
Tempting, but it misses something. That adds cost and scope beyond the stated readback requirement.
See how a strong candidate says it
“The authorized editor that committed version 42 can request at least that version; an older cache must refresh or use the authoritative path. The public-only viewer still cannot read the restricted issue.”
Why it works: Read-after-write need not require every search query to be strongly consistent.
Step 4: Reject an older refresh
What would you do here? Open the move you’d make.
Accept the latest arriving event because it was processed last.
Tempting, but it misses something. A delayed event can restore stale visibility and data.
Keep version 42 when the late version-41 event arrives.
The strong move. The cache preserves monotonic object versions.
See how a strong candidate says it
“A delayed event for version 41 must not overwrite cached version 42. Compare versions at the update boundary.”
Why it works: Event arrival order is not business order.
The answer, in short
- Decision
- Use one object version for the permission and served-data decision.
- Because
- The packet allows stale discovery, not stale authorization of restricted data.
- What would change it
- A different permission contract could permit a bounded configuration delay; it must be explicit and separate from sensitive issue changes.
Common traps
- Treating every read as equally safe to cache.
- Equating arrival order with object version.
Check your answer
- Did I distinguish search from disclosure?
- Do permission and data use the same version?
- Can an editor read its own committed version?
- Can an old event restore stale state?
Last reviewed Nov 10, 2026