A tenant in B2B is another organisation or company. However, consider whether your customers have divisions (teams or departments) and whether they have a presence in multiple countries/regions. You might need to map a single customer to multiple tenants if there are different requirements for these subgroups.
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)
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 to split/export a single customers data if needed
- Difficult 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
- Poor performance from switching between 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
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 server/databases
- Multiple places to deploy changes to - although can be automated
References
WhatIs What is multi-tenancy (multi-tenant architecture)?