How would you design retrieval when permissions change faster than the index?

The first thing I would separate is search freshness from permission freshness.

If the vector index is three hours late, a newly added document may not be found. That is a product problem. If a revoked document is still in the index and the assistant reveals it, that is a security problem. I would not make the 30 second revocation promise depend on rebuilding embeddings.

There is a deeper contract hidden in that promise. Thirty seconds after which event? A user clicks revoke in the source system? The source commits its permission change? Our connector sees it? If the source cannot tell us what changed within a bounded time, we cannot honestly promise a bound from the user's click. I would define the start event with the source owner and measure from there through the policy view used by search.

I would keep an immutable source document ID, a content version, a tenant ID, and a source permission reference for every indexed chunk. Lexical and vector indexes can contain an ACL snapshot to prune candidates early. That makes search fast. It is still only a snapshot.

The search service first restricts the tenant and, where supported, applies that coarse ACL filter before ranking. It returns candidate IDs inside a trusted boundary. Before fetching text for a reranker, context builder, model, or external provider, the service checks those IDs against the current authorization view for this principal. Anything denied is dropped. Then it fetches the permitted document version and verifies that the text behind the citation is the text being used.

That order matters. A postfilter after sending snippets to a third-party reranker is already too late. It also matters for internal logs, previews, query suggestions, and caches. All of those can reveal a restricted title or phrase even if the final answer is clean.

I would also define what happens to an answer already in flight when permission is revoked. A check before context assembly protects a new request, but a long response may still be streaming after the revocation deadline. The serving layer needs a way to invalidate that request's authorization, stop further disclosure, or recheck before releasing buffered private output. We cannot retract tokens already shown before revocation. The product contract should say exactly when a revoked grant stops authorizing new disclosure.

For 10,000 queries per second, a remote permission call per candidate could dominate latency. I would measure the distribution of candidate counts and use batched authorization. Tenant-local policy snapshots or short-lived decision caches may help, but their lifetime and invalidation must fit the revocation bound. A ten minute positive cache defeats the requirement even if the index updates in one second. If the policy system supports versioned grants, I would put that version into cache identity and invalidate on the revocation event. Cached search results should normally hold IDs, with authorization repeated when a hit is served. A cached final answer containing private text needs an even stricter scope, version, and invalidation rule. I would avoid it until those rules are proven.

Large tenants need different physical treatment from small ones. I would use tenant-aware routing and prevent one large tenant from occupying every hot shard. Some tenants can share index capacity, with a strict tenant filter at the data boundary. The very large or residency constrained tenants may need dedicated partitions or regional pools. The index topology is a capacity choice. Tenant isolation is a correctness requirement.

An authorized user might still get a poor result because the new document is not indexed. I would expose separate measures for content freshness and permission freshness. Track the time from source content version to searchable version. Track the time from revocation commit to enforcement. Sample negative permission tests, not only successful searches. Record how many retrieved candidates were denied at the final check. A sudden rise could mean the index ACL snapshot is stale. It should not become a leak, but it will waste capacity and hurt recall after filtering.

The identity service outage forces a real decision. For permission-sensitive documents, I would fail closed if I cannot obtain an authorization decision that is valid under the revocation contract. A previously cached grant may be usable only while its age and revocation mechanism still meet that contract. After that, the system can return public content, say private sources are temporarily unavailable, or fail the request. It should not quietly treat search index metadata as permission to disclose. If the business wants availability through a long identity outage, it needs a replicated, sufficiently current policy service, not a softer interpretation of the security promise.

There are two easy weak answers here. “Put ACLs in the vector database” ignores the lag between permission change and index update. “Retrieve everything and filter before the final response” ignores exposure to rerankers, logs, and the model. Some search engines have native document-level security, but I would still check its update semantics and role composition against this particular 30 second promise. Elastic, for example, documents that role permissions can combine in ways that widen access. A feature name is not the proof of the system invariant.

I would ship this behind tests that revoke a grant while a request is in flight, while a cache entry is warm, and while an index rebuild is delayed. If any path can put revoked text into a prompt after the deadline, the design is not ready.

Suppose the interviewer now takes away the vector index. I would serve authorized lexical results if that path is healthy, with an explicit degraded quality signal. Search availability can change. The tenant and permission boundary cannot.

Then they say the source sends permission events unreliably. That breaks the premise behind a bounded revocation time. I would need reconciliation against a source snapshot or a current source authorization check. Until we have a measured bound, I would change the product promise rather than claim the 30 seconds still holds.

One more detail is easy to miss. The citation is opened tomorrow by a different person. It points to evidence, but it is not an access grant. The document is authorized again at click time, and a deleted or superseded source is represented honestly rather than served from an old private excerpt.

Primary-source notes: Elastic document-level security and role composition. The fast authorization path, cache rules, and failure behavior above are a proposed architecture for this scenario, not a guarantee made by Elastic.

Related ArchCrux reading: RAG in Production Is Mostly Not About Retrieval.