Serving Many Customers from One Web App: Multi-Tenant Basics

What a tenant is

Microsoft's multitenant architecture overview defines a multitenant solution as one "used by multiple customers, or tenants", and stresses that tenants are not users. Several users from one organisation form a single tenant. Its examples range from business software such as accounting and work tracking to consumer services like music streaming.

Defining the tenant is the first decision. Microsoft's article on tenancy models says that when customers are other businesses, you likely map each customer to a tenant. You may still need several tenants for one customer, for example separate divisions or separate test and live environments. For consumer apps it is less clear: one person, a family or a club might be the tenant. Write your definition down, because accounts, permissions, billing and data separation all follow from it.

Silo, pool and bridge

The AWS SaaS Lens sorts architectures into three models:

• Silo: each tenant gets dedicated resources, such as a fully separate infrastructure stack or its own database. AWS notes that a silo is still SaaS because sign-in, onboarding and operations are shared. That is what separates it from running a separate copy of the product for each customer.
• Pool: tenants share resources. AWS calls this "the more classic notion of multi-tenancy", relying on shared infrastructure for economies of scale, easier management and agility.
• Bridge: a mix. Some parts run siloed and others pooled. AWS's example is that a component's regulatory profile or noisy neighbour risk might push it to silo, while its cost profile might push another to pool.

Microsoft's tenancy models article describes a similar range: automated single-tenant deployments, fully multitenant deployments, and vertically or horizontally partitioned deployments in between.

Choosing a model is a business decision

Microsoft says plainly that selecting a tenancy model "isn't only a technical decision. It's also a commercial decision." It asks you to weigh:

• whether lower cost per tenant or the best tenant experience matters more;
• whether your customers will accept shared infrastructure at all, given their compliance needs;
• whether a single-tenant design can scale to your growth plans;
• how much of the operations you can automate;
• whether customers expect service-level agreements.

Its rule of thumb: if you expect many customers, shared infrastructure is important, because otherwise you maintain "a large and growing fleet" of resources. If you expect only a few customers, or their isolation requirements are high, dedicated resources may fit even though they cost more. Microsoft's example is a provider for legal firms whose customers insist on their own infrastructure for compliance.

The model also shapes pricing. If some customers will pay more for dedicated resources, that ties into how you bill, covered in our guide to subscription billing for a web app.

Keeping tenants apart

AWS's tenant isolation page calls it "one of the foundational topics that every SaaS provider must address". One tenant reaching another's resources "would represent a significant and potentially unrecoverable event" for the business. AWS adds that there is no universal way to achieve it: the domain, compliance, deployment model and chosen services all play a part.

In a pooled app, isolation lives in the code and data layer. Every request must carry the tenant's identity, and every query must be limited to that tenant. Sign-in must establish which tenant a user belongs to, as covered in our guide to web app user authentication. Microsoft's guidance mentions row-level security in databases such as Azure SQL Database and Azure Database for PostgreSQL as one way to enforce this in the database itself. It also warns that this "can be complex to design, implement, test, and maintain". Whatever the method, test it: automated tests that try to read another tenant's data are worth writing from the start.

Where each tenant's data lives

Microsoft's article on storage and data in multitenant solutions lays out the options for databases:

• Shared tables with a tenant identifier column, which supports large numbers of tenants;
• Separate databases per tenant;
• Sharding: several databases, each holding one or more tenants, without duplicating the rest of the system;
• Deployment stamps: whole copies of the solution, each serving a group of tenants.

It also names antipatterns. One is a separate set of tables per tenant inside one database, which becomes hard to query, manage and update as tenants grow. Another is adding columns for a single tenant's needs, which becomes unmanageable with many customisations.

Where data lives matters beyond the database. Microsoft notes that consumer tenants raise questions about personal data and data sovereignty laws in each place you serve, and business tenants bring their own compliance and isolation requirements. That links the tenancy model to your hosting region, covered in our guide to web app hosting options.

The noisy neighbour problem

Microsoft's noisy neighbour antipattern page describes what happens when one tenant uses "a disproportionate amount" of shared resources and performance degrades for others. It can also happen when many small tenants peak at the same time. Microsoft says the risk cannot be completely avoided when resources are shared, but suggests steps for the provider:

• monitor resource use overall and per tenant, with alerts on spikes;
• enforce quotas through throttling or rate limiting, so one tenant cannot overwhelm the system;
• add capacity by scaling up, or out with shards or stamps;
• let tenants buy reserved capacity;
• rebalance tenants across instances, and move heavy background work to quieter times.

Plan limits per plan: storage, users, API calls or exports. They protect other tenants and give you a clear basis for pricing tiers.

What to settle in the brief

• What a tenant is in your product, and whether one customer can have several.
• Silo, pool or bridge, and whether any customers will pay for dedicated resources.
• How tenant isolation is enforced and tested.
• How each tenant's data is stored, in which region, and how one tenant's data is exported or deleted on request.
• Per-tenant limits and monitoring.
• How a new tenant is onboarded: self-service sign-up or set up by your team.

Our guide to writing a web app project brief shows where these decisions fit alongside the rest of the plan.

Frequently asked questions

What is a multi-tenant web app?

One application that serves several customers, called tenants, each with its own users and data. Microsoft stresses that tenants are not users: many users from one organisation form a single tenant.

What are the silo, pool and bridge models?

AWS's SaaS Lens uses silo for dedicated resources per tenant, pool for shared resources, and bridge for a mix where some parts are siloed and others pooled.

Should each customer get its own database?

It depends on how many customers you expect and how strict their isolation needs are. Microsoft says shared infrastructure matters if you expect many customers, while dedicated resources may suit a few customers with high isolation requirements, at higher cost.

What is a noisy neighbour?

A tenant whose heavy use of shared resources degrades performance for others. Microsoft suggests monitoring use per tenant, enforcing quotas through throttling or rate limiting, and adding or rebalancing capacity.

Planning a web app for many client companies? See our web app development service and all our services, or email [email protected].