Role
Platform engineer for multi-tenant SaaS
A customer opens a ticket saying they can see a record that is not theirs. Everything else stops, because that sentence is the worst one a multi-tenant system can produce.
How I fit
I work on the layer every feature sits on: how tenants are isolated, how a request resolves to a tenant, how access is decided, and how work runs on behalf of a tenant in the background. Getting that layer right is invisible. Getting it wrong is the only kind of bug that ends a customer relationship in one afternoon.
A challenge from this role
A customer reports seeing a record belonging to another customer. Nothing else matters until that is understood. The likely cause is not exotic, it is one query missing a tenant predicate, written months ago in a hurry, in a code path nobody exercises often.
How I approach it
Contain first. Establish the blast radius from the logs before touching code, because whether one record was exposed or a thousand determines who has to be told and what has to be disclosed. Then fix the specific query, and then, in the same week, remove the possibility of the class. If isolation depends on every developer remembering a predicate on every query, it will fail again, so it has to move into the database or into a layer that cannot be bypassed. A postmortem that ends at the query is a postmortem that schedules the next incident.
What proves it
A platform serving 112 tenants, where isolation is structural rather than a filter somebody remembers.
Database per tenant against a shared schema, with the real operational cost of each.
Capability separated from authority, so a permissions mistake is a visibility mistake rather than a money mistake.
Job identity scoped by tenant, because without it one tenant's work silently deduplicates against another's.
Schema changes across many tenant databases while customers are using the system.
Why this one invariant is different
Every system has bugs. Most of them cost time, or a number, or a bad afternoon.
Cross tenant exposure costs the customer relationship, and often triggers a disclosure obligation. It is the one failure where the technical severity and the commercial severity are the same thing.
That asymmetry justifies spending disproportionately on it. A structural guarantee that costs a week is cheap against an outcome that cannot be undone by an apology.
Structural, not remembered
The distinction the whole role turns on.
A remembered guarantee is one where a developer must apply a tenant predicate on every query. It works, because people are careful, until the one query written under time pressure in a code path nobody exercises.
A structural guarantee is one where the predicate is applied below the application, or a query without a tenant scope cannot compile or cannot run. The difference is not rigour, it is whether correctness depends on attention.
The postmortem test
After a cross tenant incident, the question that matters is not what caused it. It is what class it belonged to, and whether that class is now impossible.
A postmortem that ends at the specific query has scheduled the next incident.
Questions people actually ask
- What is the most common multi-tenancy mistake?
- Treating isolation as a filter rather than a property. A filter is something a person remembers on every query, and people are consistent until the week they are not.
- How do you test isolation?
- With a test that fails if any query touching tenant data can run without a tenant scope, rather than by asserting behaviour case by case. Tests of instances do not cover a class of mistake.