ORIGINAL COMPANY-CONTEXT PRACTICE
Revoke access across cached enterprise services
Original practice scenario: A hypothetical productivity platform caches document permissions. A user is removed from a team while a long-running export is active. Design the authorization boundaries.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Define when revocation must take effect and which actions require a fresh decision. A cache expiration policy alone may leave long-lived jobs authorized after their permission changes.
Work through it
- Attach tenant, principal, resource and policy version to authorization decisions; keep caches scoped to those identities rather than just document URLs.
- Recheck authority at sensitive stages such as starting an export and delivering its output, with a revocation event or bounded cache lifetime.
- Cancel or quarantine affected jobs, retain an audit trail without document contents, and test delayed revocation messages and service partitions.
Tradeoffs to discuss
- Immediate checks improve revocation guarantees but add dependency latency; bounded caches need an explicitly accepted exposure window.
Common pitfalls
- Do not authorize a download solely because an earlier computation was permitted.
- A user changing tenants or reusing a session must not inherit cached authority from another organizational context.