When designing system architecture, consider how customer data is segmented. This page discusses common segmentation types and uses the term "tenant" to indicate a logical grouping of data or services for a particular entity—whether a customer, region, or team—depending on the application.
In business-to-business (B2B), a tenant typically represents another organization or company. However, if your customers have divisions (teams or departments) or operate across multiple countries or regions, you may need to map a single customer to multiple tenants when these subgroups have different requirements.
Diagram
Model 1
A single code base and a single database. Multiple tenants (customers) are held in a single database structure and logically separated using primary keys and/or security features of the database (row permissions). Multiple tenants share the same database table structures.
Pros
- Code easy to deploy (single location)
- Infrastructure likely lower cost
Cons
- Needs robust security model in code to enforce separation
- Requires developer skills to be aware of potential security issues to prevent leak of data between tenants.
- Difficult/complex to split & export a single customers data if needed
- Difficult/complex to delete customer data at end of contract
- Risk of damage to all customers if mistake made or security concerns are found
- Loss of system affects all customers
Model 2
A single code base and multiple customer databases. Data for each customer is isolated.
The code has to continuously switch between databases depending on the user accessing the system.
Pros
- Data is segmented
- Single front end makes deployment easier
Cons
- Can experience poor performance from switching between multiple databases
- Difficult to write code to context switch between customers/brands
- Needs robust security model in code to enforce separation
- Risk of damage to all customers if mistake made or security concerns are found - single code base
- Loss of system affects all customers
- Database structure changes need to be deployed to multiple databases at the same time to maintain compatible front end code.
Model 3
A single code base with a dedicated database for each customer. Each customer also has their own front-end instance, which typically uses cloned common code but runs separately.
Pros
- Each tenant is totally isolated
- Can prevent accidental leak of data across databases/systems
- Each customer could be deployed near physical customer - e.g. Australia/USA/UK etc.
- Each customer is deployed in a similar fashion, templated deployment
- Loss of a single system doesn’t affect all customers
- Each customer could have a customised version of the software (try and avoid this if possible or use feature flags to enable features as required)
- Systems can be individually scaled up/down to meet needs of customer
Cons
- Higher infrastructure costs - multiple front end servers & databases
- Multiple places to deploy changes to - although could be automated
References
johndowns Tenancy models for a multitenant solution - Azure Architecture Center