Every software company that builds an application serving more than one customer has to answer this question.

Should each customer get a separate copy of the system, or should they all share one?

Running a dedicated copy per customer is easy to reason about, but the cost of maintaining hundreds of separate copies increases with every new customer. On the other hand, sharing a single system across all customers is far cheaper. This is why most of the software we use every day is built to be shared rather than duplicated. Such systems are known as multi-tenant systems, where each customer is a tenant that shares resources with other tenants.

However, sharing is also where the difficulty begins.

Once many customers rely on the same database, the same servers, and the same background jobs, their fortunes become linked. For example, one customer running a heavy report can slow the service for everyone alongside them. A single faulty deployment can impact all of them at once instead of just the customer. And the most serious risk is around data leaks, where one customer is shown data that belongs to another. All of these situations have to be actively handled by a multi-tenant system.

In this article, we will understand multi-tenant architecture from the basics, along with its various benefits and challenges. Here’s a quick overview of what we will cover:

• What a tenant really is.

• Where each customer’s data can physically live, from one shared set of tables to a database of its own, and what each of those options costs.

• Why the same choice between isolating and sharing also includes the compute layer and beyond, not only in the database.

• The noisy neighbor problem, and why sharing can impact fairness and force a team to rebuild it with quotas and limits.

• The role of blast radius in such an architecture.

• The concept of tenant context that runs through every part of the system.