Multi-tenancy: the decisions you cannot reverse later
Almost every architectural decision in a product can be revisited under pressure. A handful cannot, because they are assumed by every line of code written afterwards. In multi-tenant business software, four of them arrive in the first fortnight and are usually made without discussion.
2 min readOadbox
One: how tenants are isolated
Shared tables with a tenant column, a schema per tenant, or a database per tenant. Each is defensible; each has a different answer for noisy neighbours, per-tenant restore, regulatory isolation and the cost of running a thousand small customers.
What matters more than the choice is enforcing it below the application layer. Isolation implemented as a condition that developers must remember to add will eventually be forgotten, and that is the incident nobody recovers their reputation from.
Two: whether a user belongs to one tenant or many
The natural first model is a user inside an organisation. Then a parent has children in two schools, an accountant serves nine clients, or a group operates six hospitals — and the identity model has to change underneath everything already built.
Separating identity from membership at the start costs a day. Retrofitting it costs a quarter and touches every screen.
Three: what a record is scoped to
Tenant is rarely the only boundary. Branches, campuses, plants, depots and cost centres all need scoping, and users need access to some but not all.
- Is scope hierarchical, and can it be re-parented later?
- Can a user hold different roles in different branches?
- Do documents number per branch, or per tenant?
- Can data move between branches, and what happens to its history?
Four: where the tenant clock is
Time zone, financial year start, week start and holiday calendar all belong to the tenant, not to the server or the user's device. This sounds trivial until a report disagrees with a customer's own day-end by a few hours.
Storing everything in a single canonical zone and converting at the edges is the only version of this that survives contact with a group operating in more than one country.
Written by the Oadbox team. Something here not match how it works in your business? We would genuinely like to hear it — connect@oadbox.com.