ORIGINAL COMPANY-CONTEXT PRACTICE
Propagate revoked record access
Original practice scenario inspired by Salesforce, Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A synthetic CRM search service caches permission-filtered results. An administrator revokes a user's access while cached results and search indexes still contain the record. Design a read path that handles revocation responsibly.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Treat authorization as a current read decision, not merely an indexing-time filter. Cached discovery results may improve speed, but they cannot be the sole authority after permissions change.
Work through it
- Include tenant and user authorization context in cache keys and isolate tenants throughout indexing and retrieval. Version permission state and publish revocation events reliably.
- Recheck access against an authoritative or sufficiently fresh authorization layer before returning sensitive record content. Invalidate affected caches and indexes asynchronously as a secondary measure.
- Test revocation during an in-flight search, stale caches, group membership changes, and unavailable authorization services. Define a fail-closed behavior for sensitive reads.
Tradeoffs to discuss
- Per-read checks add latency and load. Bounded permission caches need explicit freshness guarantees and stronger handling for revocations than ordinary content updates.
Common pitfalls
- Removing a result from the next index build leaves a leakage window.
- A cache key lacking tenant identity risks cross-tenant disclosure even without stale permissions.