I've had a few interesting conversations with folks regarding multitenant systems over the past few weeks. Those conversations prompted me to distill my knowledge and outline how to design, build, and operate multitenant systems. This post is the first of a multi-part series. This post will look at the basics of designing multitenant systems and aspects of tenant modeling. Future posts will cover lifecycle management, pricing strategies, failure, and update domains, capacity planning, as well as architectural approaches for building multitenancy systems.

A tenant can be defined as a group of users from a single organization or company. A multitenant solution is one used by multiple tenants. Examples of multitenant applications include:

• Software as a service (SaaS) products. These could be Business-to-business (B2B) solutions like payroll management or Business to consumer(B2C) solutions like Slack.

• Enterprise-wide platform solutions, such as an internal developer platform(IDP) or a shared Kubernetes cluster used by multiple teams and business units within an organization.

When building a multitenant architecture, there are several decisions you need to make and alternatives you need to consider. Many of these decisions are business-driven and can lead to different architectural models. However, I've found that asking the right questions can help develop the right architecture.

• What defines a tenant for you? Is it a single user, a team, a specific portfolio, or an organization as a whole?
• What pricing models do you support, and how will the pricing models impact the requirements?
• What level of service do you provide to each tenant? For example, do you treat each tenant equally from an availability or resilience perspective?
• How would you do capacity planning or handle scale as the number of tenants grows?
• How will your infrastructure support multi-tenancy, and what level of isolation is required?
• How would you handle tenant-specific requirements?
• How will you monitor, manage, automate and scale your environment?

Tenant Modeling

One of the first steps to designing a multitenancy system is to define who the tenant is and the extent and mechanism of isolation required from a multi-tenancy perspective.
Your definition of tenant will impact some of the things you need to consider when you architect your solution. For example, if your tenants are end consumers(B2C), you might need to factor in things like geographical and locale-specific requirements. On the other hand, if your tenants are businesses(B2B), you need to factor in requirements for regulatory compliance, data isolation, and service-level objectives (SLO), such as availability.

Tenant Segregation and Isolation

Tenants can be segregated either logically or physically.
Physical segregation is when you maintain separate infrastructure per tenant. Although this can sound appealing, it can quickly become expensive as you scale, and the number of tenants grows. It also typically leads to under-utilised resources. Consider physical segregation if there are strong compliance and regulatory requirements.
Logical segregation is when tenants share infrastructure. The system maps customers to the infrastructure their data and applications live on so that you can route their traffic to the correct infrastructure.
A key difference between logical and physical segregation is how isolation is enforced. When multiple logical tenants share infrastructure, you typically rely on your application code and tenant identifiers to separate each tenant's data. However, when you have physical tenants, they have their dedicated infrastructure, so it may be less important for your code to be aware that it operates in a multitenant environment.
One of the most significant considerations when designing a multitenant architecture is the level of isolation that each tenant needs. Unfortunately, I've generally seen people err in this area. They tend to look at isolation in binary terms where there is a shared-nothing model on one end of the spectrum and on the other is a fully shared model.
However, it is helpful to think about isolation being a continuum with shared-nothing at one extreme and a fully shared at the other. In most cases, the sweet spot lies somewhere in-between, with some components being shared and others isolated.
The level of isolation impacts many aspects of architecture, including the following:

• Security. If you share infrastructure between multiple tenants, you need to be especially careful to isolate data. In addition, the strategy you use for identity management needs to include both tenant and user identity.
• Cost. Multiple tenants can use shared infrastructure, so it's cheaper.
• Noisy Neighbour issues with respect to Performance and Reliability.
• Responsiveness to individual tenant needs. When you deploy infrastructure dedicated to one tenant, you can tune the configuration for the resources for that specific tenant's requirements.