ORIGINAL COMPANY-CONTEXT PRACTICE
Isolate tenant-specific retrieval caches
Original practice scenario: A hypothetical enterprise assistant serves several organizations using shared infrastructure. How should caching avoid cross-tenant evidence disclosure?
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Cache identity must include the authorization and content context that affects a result. A shared query string alone is unsafe when tenants have different documents or permissions.
Work through it
- Include tenant, entitlement scope, document snapshot and retrieval configuration in cache keys; avoid placing sensitive raw prompts in observable identifiers.
- Revalidate access when cached evidence is consumed, expire or invalidate entries after permission changes and keep per-tenant limits on cache growth.
- Test identical queries across tenants, revoked roles, document replacement and concurrent invalidation; inspect logs and metrics for accidental content exposure.
Tradeoffs to discuss
- Fine-grained keys improve isolation and freshness but reduce cache reuse; coarse keys require stronger filtering and are easier to misuse.
Common pitfalls
- Do not assume tenant separation in the user interface enforces data separation.
- A cached generated answer can remain sensitive even when its cited document has been removed.