Why it matters
A tenant boundary is a rule enforced throughout the application, not just a tenant ID column. Isolation can be logical in shared infrastructure or physical in dedicated resources, and each choice has different failure modes.
A multi-tenant product shares infrastructure while keeping customers separate. The boundary must hold in ordinary queries, background jobs, caches, exports and support tools alike.
Decisions to make
- Choose the tenant boundary for reads, writes, queues, files and caches.
- Decide which operations may cross tenants, such as support or analytics.
- Define how tenant context enters a request and propagates to background work.
- Choose where tenant context is established and how it flows through jobs.
- Decide when a customer needs a stronger isolation tier.
Build checklist
- Require tenant context at every data access boundary.
- Test a caller with valid credentials trying to access another tenant’s object.
- Include tenant identity in audit events and operational traces without exposing secrets.
- Run cross-tenant tests against reads, writes, search and exports.
- Include tenant identity in audit events and data access checks.
Common mistakes
- Adding a tenant filter to the UI while leaving unscoped queries in the service.
- Filtering only in the UI while backend queries remain broad.
- Trusting a tenant ID supplied by an untrusted client without authorization.
Tools & references
3 starting points to compare or study. Check fit, maintenance, terms and current capabilities before choosing one.
