Design Multi-Tenant Isolation

The answer, out loud

What a strong answer to “Design Multi-Tenant Customer Isolation” sounds like, first question to last trade-off. It is about 6 minutes of talking; the whiteboard and the interviewer fill the rest of the 45. Read it aloud once, then close the page and give it yourself.

1. 0–4 min

   What isolation actually promises

   I want to say what isolation means before I draw anything, because it is three promises and they fail in different ways. Data: a customer never sees another customer’s rows. Performance: one customer’s worst day is not everybody’s. Configuration: customers can differ without forking the product. We are sharing infrastructure because that is what makes this economical — a whole stack per customer is fine for ten and impossible for thousands. So the job is not to avoid sharing, it is to make sharing safe. And the data promise is the hard one, because it is the only failure that is silent, permanent and legally interesting.

2. 4–9 min

   One shared stack, one front door

   The skeleton is a shared gateway in front of a shared app tier and a shared store. I draw it that way because what I care about first is that there is exactly one front door. Everything I add after this — context, quotas, keys, audit — is enforcement, and enforcement needs a chokepoint. If a large customer or an internal service can reach the app tier directly, or an analyst can open a replica by hand, then my rules hold on most paths, and most is not something you can claim to a security reviewer.

   Built in step 1: Many customers, one system
3. 9–16 min

   Make forgetting unavailable

   Now the isolation itself. The version that fails is the one where every query is supposed to filter by customer and everyone is trusted to remember. Someone forgets once and that is a breach, so I do not want discipline, I want forgetting to be unavailable. The gateway authenticates the user, resolves the tenant the request is acting in, and puts that id into a context the data layer applies to every query unasked. The useful consequence is that code review stops being the control. The control is that scoping is implemented in one place, so a reviewer reads one thing carefully instead of everything hopefully.

   Built in step 2: Inject tenant context
4. 16–24 min

   Where the data sits

   Where the data sits is a spectrum, and I would resist answering it once for everyone. A shared table keyed by tenant id is cheapest and carries the long tail. A schema per tenant gives visible separation with one database to operate. A database per tenant is the strongest and it multiplies backups, migrations and monitoring. I would default the long tail to shared and reserve silos for customers whose compliance actually demands it. What I want agreed in the room is that this is a commercial decision with an operational price — if a silo closes the deal, fine, but it should be sold, not given away.

   Built in step 3: The isolation spectrum
5. 24–30 min

   The neighbor problem

   Data separation still leaves the failure customers actually feel: one tenant spikes and everyone else gets slow. Filtering does not help with that. I would put per-tenant rate limits and resource caps at the gateway, so a burst is throttled against that customer’s own budget instead of draining the shared pool. The tempting alternative is to scale up when it happens, and I would argue against it in the room: capacity arrives after the spike, it does not stop one customer taking whatever you added, and it turns one customer’s abuse into everyone’s bill. Adding servers answers growth. Quotas answer unfairness, and those are different problems.

   Built in step 4: Per-tenant quotas
6. 30–36 min

   Keys and config per customer

   Then secrets. Under one shared key a single leak is every customer at once, so the blast radius of one mistake is the whole business. A key per tenant bounds it to one customer, and it buys the thing compliance always asks for: deleting a customer becomes destroying a key rather than hunting their rows through every system that ever touched them. I would keep per-tenant configuration beside the keys — features, limits, branding — because the alternative is per-customer branches in the product, which is how a shared system drifts back into one deployment per customer without anyone deciding to.

   Built in step 5: Per-tenant keys + config
7. 36–42 min

   Evidence instead of confidence

   Last, proving any of it holds, because a leak can run for months with no symptom — no errors, green dashboards, and the first person to notice is a customer who saw a name they recognised. So, two things. A per-tenant audit trail of who read and changed what, which is both the compliance artefact and the tripwire. And tests that take tenant A’s credentials and deliberately try to read tenant B, run on every deploy, failing the build the moment one succeeds. That turns we are careful, which is unfalsifiable, into a property that was checked this morning.

   Built in step 6: Audit + isolation testing
8. 42–45 min

   Close on the trade-off

   So: one shared stack, tenant context injected at the edge, storage chosen per customer along a spectrum, quotas for performance isolation, a key and a config per tenant, and audit plus cross-tenant tests to prove it. The whole design is one trade-off restated at every step — separation costs efficiency or operational load, and the skill is spending that where a customer’s trust needs it rather than everywhere. With more time I would work on per-tenant observability, so I can say whether something is slow for everyone or only for this customer, and on what happens when one customer contractually wants to pin a release while everyone else moves on.