Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Classify isolation requirements across identity, data, encryption, compute, network, operations, residency, and failure. Define whether dedicated means separate schema, account, cell, region, or full deployment.
Establish scale assumptions
- Model tenant size and risk distributions, hot tenants, migration volume, and fragmentation cost. Most tenants may share cells while a small tail requires stronger boundaries.
Functional and non-functional requirements
- Prevent cross-tenant access, contain resource and failure blast radius, support tier changes, produce audit evidence, and keep shared operations economical. Isolation must apply to asynchronous and support paths.
High-level architecture
- Use tenant context from authenticated identity, policy enforcement at services and data access, tenant-aware caches and queues, per-tenant encryption envelopes, quotas, and cell placement. Offer dedicated cells or accounts for the highest tier.
Data model and flow
- Carry immutable tenant identity through request, event, job, and storage keys. Validate context at every trust boundary and include placement epoch so migrations cannot write to an old cell.
Consistency and transaction boundaries
- A tenant directory authoritatively maps tenant to cell, policy, and key version. Placement changes use dual-read or snapshot-log transfer with fenced writes and reconciliation.
Failure modes and recovery
- Bound queues, pools, and storage hotspots per tenant and cell; keep control traffic separate. Cell loss affects only assigned tenants and has a rehearsed evacuation path.
Security and privacy
- Enforce row or partition policy in depth, use per-tenant keys where needed, isolate privileged support, and test cross-tenant negative cases continuously. Never trust client-provided tenant identifiers.
Observability and SLOs
- Track authorization denials, context loss, resource use, saturation, cell health, and access by tenant without leaking other tenants’ details. Alert on records or cache keys missing tenant scope.
Capacity and cost
- Price stronger isolation for dedicated keys, capacity, accounts, and operations. Use shared cells for efficiency and define objective graduation triggers from risk, compliance, or sustained load.
Alternatives and trade-offs
- Database-per-tenant provides strong boundaries but creates fleet operations and fragmentation; shared tables scale the long tail but demand rigorous context enforcement. Graduated cells combine both.
Evolution and migration
- First make tenant context explicit and testable, then add quotas and cells, then migrate selected enterprises using fenced placement. Avoid promising dedicated topology before operations and upgrades support it.
What Staff and Principal candidates should emphasize
- Strong candidates treat isolation as several independent dimensions and tie tiers to contracts, cost, and migration. They cover background jobs, support tools, caches, and failure—not only SQL.
Decision trade-offs
Data tenancy
Option A
Shared tables with tenant partition keys
Option B
Separate databases or cells
Recommendation:Use shared storage for the long tail under defense in depth; graduate tenants when regulation, load, or contract value justifies stronger boundaries.
Encryption
Option A
One platform key hierarchy
Option B
Per-tenant data keys or customer-managed keys
Recommendation:Use envelope keys per tenant for higher tiers and customer-managed roots only when lifecycle and availability obligations are explicit.
Follow-up interview questions
- 01How does a tenant move from shared to dedicated without downtime?
- 02Can one support engineer query multiple tenants?
- 03What does a dedicated deployment guarantee and not guarantee?
- 04How do cache and queue designs prevent cross-tenant leakage?
Common weak answers and mistakes
- 01Treating a tenant_id column as the complete isolation design.
- 02Accepting tenant identity from request parameters instead of trusted authentication.
- 03Offering dedicated deployments without an upgrade and incident operating model.
- 04Ignoring asynchronous jobs, logs, support tools, and encryption boundaries.
Interviewer evaluation rubric
Relies on row filters and rate limits without defense in depth, placement, or operational isolation.
Propagates trusted tenant context, adds policy, quotas, tenant-aware storage, keys, and shared cells.
Defines graduated tiers, fenced migration, cell failure domains, support controls, continuous tests, and pricing.
Aligns technical boundaries, enterprise promises, unit economics, and a scalable operating model across the full tenant lifecycle.