Documentation / Learn / Tenant boundaries and data separation on the platform
Tenant boundaries and data separation on the platform
In Short
Shared infrastructure only earns trust when each customer's data, users, and configuration stay verifiably separate. QueryTek treats the tenant as the primary boundary and applies isolation, multi-tenant delivery, and modular bounded contexts so operators always know which organization they are acting on, without publishing the mechanics that enforce it.
Industry Context
Multi-tenant delivery is the economic basis of modern SaaS, and it is also the first thing a security architect interrogates. The questions are concrete: can one customer's administrators see another customer's people, can a misconfigured integration write into the wrong workspace, and does an engineer running a support query have any way to cross a boundary by accident?
These come up in security reviews and architecture calls long before anyone opens a design document. They are hard to answer well because the honest answer involves enforcement detail that should not be public, while a vague answer sounds evasive.
The useful middle ground is to be precise about the model and reticent about the implementation. A reviewer who understands that tenancy is enforced at the data layer rather than assembled per-feature in application code has learned the thing that actually matters, and has learned it without receiving a map of the system.
How QueryTek Applies It
Tenant: The tenant is the primary workspace boundary — the unit that owns data, users, and configuration. Every meaningful action in a QueryTek product happens inside exactly one tenant, which is what makes "which customer does this belong to" a question with a single answer.
Tenant Isolation: Isolation is the outcome that boundary is supposed to produce: one customer's documents, people, and settings remain unreachable from another's. QueryTek states this as an enforced property of the platform rather than a convention each feature is trusted to follow.
Multi-Tenancy: Multi-tenancy describes serving many organizations across shared product families while keeping those workspaces distinct. Shared operation is what keeps the platform economical; the boundary is what keeps it safe.
Row-Level Security: Row-level security names the pattern of enforcing tenant scope where the data lives, so a query cannot return rows outside its tenant even if calling code is wrong. Public documentation covers the concept and its consequence, not policy definitions.
Bounded Context: Bounded contexts let Review, Tapestry, and EBM evolve on their own terms without renegotiating separation guarantees, which is how modular product work stays compatible with a platform-wide promise.
Readers should finish with a separation story they can repeat accurately. They should not receive SQL, policy names, or storage topology.
