Mental model#
Multi-tenant authorization preserves a boundary between customers even when compute, caches, queues, indexes, and operations are shared. Tenant context must come from trusted membership and authoritative resource state, then follow every read, write, event, cache key, export, and support action.
Mechanism and state flow#
- Authenticate the principal and resolve current tenant memberships from a trusted source.
- Load the resource and derive its tenant server-side before returning fields or applying mutation.
- Enforce tenant plus action policy in the service and at storage/query boundaries where possible.
- Partition cache keys, queue messages, search filters, object paths, telemetry access, and background jobs by trusted tenant context.
- Audit cross-tenant administrative access, membership changes, exports, and deletion with explicit ownership.
Concrete example#
A report worker processes queued tenant exports
The message carries an immutable job ID, not trusted free-form tenant scope. The worker loads the owner-scoped job, obtains a constrained service identity, queries with tenant predicates, encrypts the output, and records the authorized requester.
Architecture consequence: Reconstruct authority from persisted owner state at asynchronous boundaries instead of trusting message attributes alone.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Shared tables with tenant key | Scale and operations favor shared storage with strong query enforcement. | Every query, index, cache, and migration must preserve the tenant predicate. |
| Schema or database per tenant | Isolation or compliance outweighs fleet complexity. | Provisioning, migrations, pooling, and cross-tenant operations become expensive. |
| Support impersonation | Only with explicit product need and controlled approval. | It creates a privileged cross-tenant path requiring strong audit and expiry. |
Failure diagnosis#
- Failure
- A cache key uses object ID without tenant ID.
- Impact
- The same identifier in two tenants can return one tenant's data to another.
- Detection
- Cross-tenant tests alternate identical object IDs and observe cache contamination.
- Mitigation
- Include trusted tenant and authorization-relevant version in keys, and reauthorize sensitive results after cache lookup.
- Trade-off
- More specific keys reduce cache sharing and hit rate.
Checklist exercise#
Work the scenario before revealing your answer
- Trace tenant context through API, database, cache, queue, object storage, search, logs, and support tooling.
- Write negative tests for same-ID cross-tenant reads, writes, exports, and cached responses.
- Name the owner and expiry of every administrative bypass.
Level calibration#
| Level | Useful evidence |
|---|---|
| SDE I–II | Apply server-derived tenant predicates and negative tests to every endpoint. |
| Senior | Carry isolation through caches, jobs, storage, search, exports, and migrations. |
| Staff | Choose an isolation model, define privileged operations, and make privacy, reliability, and cost trade-offs explicit. |
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Where does tenant context originate?
- Can a background worker exceed the initiating user's authority?
- How do cache and search indexes preserve isolation?
- How are support access and deletion proven?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.