Why one tenancy key, and only one
Isolation fails at the seams. When a system carries two overlapping notions of tenancy — an organization identifier in one place and an account or company identifier in another — some queries filter on one and some on the other, and the tables that filter on neither become the leak. A single, non-negotiable key removes the ambiguity: either a row carries it or the row does not belong to a tenant.
The four surfaces isolation has to cover
- Direct reads: every query scoped by the tenancy key at the database layer.
- Writes: the key stamped from a server-resolved source, never from the request body.
- Background work: scheduled jobs and webhooks that run without a user still need a resolved tenant.
- Live streams: realtime subscriptions and file storage paths scoped the same way as tables.
How to verify it rather than trust it
Create two organizations. Sign in as a member of the first. Attempt to read and to modify a record that belongs to the second, addressing it directly by identifier rather than through the interface. Repeat for each surface: table read, table write, file download, realtime channel. Isolation is demonstrated by the failures, not by the interface looking correct.