In a multi-tenant product all customers may use the same application, but every query, file, cache and log must stay within the right customer’s boundaries. Data isolation is not a single filter but an end-to-end architecture decision.
Isolation models
A separate database per customer can give the strongest physical separation, but operations and maintenance cost grows. Separation by tenant column in a shared database can be more efficient; then no layer of queries may skip that scope. A schema-based approach strikes a different balance between the two.
Do not think only of the database
- Cache keys must carry the tenant identity.
- File paths and object storage folders must be separated.
- Search indexes and report queries must preserve scope.
- Background queues must carry the right tenant context.
- Logs and support screens must not show sensitive data to another customer.
Authorisation must be checked twice
The requesting user’s role and the tenant owning the resource must be verified separately. Even if the user is signed in, they must not reach another customer’s records by guessing IDs.
Test scenario
Create two trial customers. With one customer’s user account, try reaching the other’s IDs, files, reports and background jobs. Without automating these tests, multi-tenant security is not complete.