Building Scalable SaaS Application with Multi-Tenant Architecture

Around 70% of corporate software is SaaS. The majority of this software has multi-tenant architecture. Are you planning to create innovative business software? Then, multi-tenancy in the cloud is your best bet. In this article you will learn about:

– multi-tenant architecture,

– difference between multi-tenant vs single-tenant,

– multi-tenancy types,

– multi-tenant database architecture,

– multi-regional deployment,

– microservices and more.

🗄 What is a Multi-Tenant SaaS Architecture?

So, what is multi-tenancy? First, let’s discuss what is a tenant in cloud computing.

SaaS & multi-tenant architecture

Multi-tenancy is crucial for SaaS products. These two go hand in hand very often. So, the terms are often confused. Let’s clarify them. SaaS stands for “software as a service”. This is a business model. Its main characteristics are:

– subscription-based payments,

– typically, a multi-tenant architecture,

– software owners handle updates and maintenance.

Under a classic SaaS business model, software owners run their apps in the cloud. They sell access to it.

Multi-tenancy is a software architecture approach.

Each tenant can add multiple users – their employees. These employees, in turn, will have subordinate workspaces. These are a part of the larger tenant space. Thus, company employees can communicate with their colleagues and access company data. But they cannot know who other tenants are or what they do.

SaaS owners must make sure that the data of different tenants does not mix. Or this would bring security risks to their clients.

🗄 Multi-Tenant vs 📁 Single-Tenant Architecture

The software can be multi-tenant or single-tenant. Multi-tenancy is more common for SaaS products. And single-tenancy is usually used for traditional software. This is when users buy a license for software. Then, they host it themselves. Yet, in certain cases, single-tenancy can benefit a SaaS application.

How does it work? Single-tenant vs multi-tenant solutions

The main difference between multi-tenant versus single-tenant architecture is the number of software instances.

In the case of multi-tenancy, there is only one software copy. Software owners run it in the cloud and make it scalable. So, many tenants can use it. They also take care of it, providing maintenance and updates.

With single-tenancy, each tenant has a separate software copy. If we are talking about SaaS, software owners help clients to customize and manage the software. They will likely provide updates too.

Now, let us explore the main benefits of both approaches:

Advantages of Multi-Tenant Architecture

1. ⚡ Efficient resource use

In multi-tenant apps, tenants share resources. Depending on the type, it can include:

– computing capacities,

– storage space,

– network bandwidth and

– database resources.

Thus, you can use resource pooling. This means that you can distribute available resources between clients efficiently based on their needs.

With single-tenancy, you need dedicated resources for each client. During off-hours these resources are underused.

2. 🔧 Easier maintenance

With cloud multi-tenancy, maintenance is centralized. This means that developers can create and deploy updates for the entire application. With single-tenancy, they must update each software copy separately.

Centralized maintenance is much faster and provides consistency. It also allows for a fast response to security threats.

3. 📈 Overall software scalability

Scalability is developers’ top priority when designing multiple-tenant architecture. Software must be ready for an ever-growing client list. Client onboarding also must be fast and easy. Developers use various techniques to improve scalability. A good example is the microservice architecture approach.

4. 💶 Better price

Price is the main reason why multi-tenancy is so popular. It allows software owners to use economies of scale. They maintain one product. There is less customization. Infrastructure is cheaper. And you don’t need to update every instance separately. This saves labor costs. So, multi-tenant apps are much cheaper to build and operate.

Benefits of single-tenant vs multi-tenant

1. ⚙️ More customization options

Single-tenancy makes customization easier. Some companies have very specific needs. For them, single-tenancy might be a better option.

2. ⚖️ Better compliance

Many countries have strict rules that companies must follow. Often, they control how organizations use, store and transfer citizens’ data. For example, EU companies must observe GDPR. And US companies in the healthcare industry must follow HIPAA.

With single-tenancy, you know exactly where your servers are. So, it is much easier to follow all the necessary rules. Customization also helps to comply. Especially, if you operate in a highly regulated industry.

3. 🔋Higher reliability

Earlier, we said that in multi-tenancy, resources are distributed between tenants. This is efficient. But the downside is lower reliability. If a tenant suddenly has a spike in traffic, they will slow down others. Developers call it the “noisy neighbor” problem. To avoid this, you can opt for single-tenancy. Or ask the provider what uptime they guarantee. We will talk more about it in the SLAs section.

4. 🛡️ Better data security

With a single-tenant approach, your data is stored and processed separately from other clients. This provides better isolation. More isolation means better security. But it also leads to higher costs. Some multi-tenancy types offer better isolation than others. But more on this later. The key is to set priorities and find the right balance.

5. 📊 Effective resource scaling for individual tenants

We mentioned that overall app scaling is better for multi-tenant apps. But scaling resources for individual tenants is easier with single-tenancy.

🔠 Types of Multi-Tenant SaaS Architectures

There are different approaches to cloud multi-tenancy. The main two types of multi-tenancy are logical and physical segregation.

Logical vs physical multi-tenancy segregation

In both cases, tenants share the same software instance. This means that there is only one copy of the software that runs in the cloud. Yet, within this copy, companies can have separate or shared infrastructure, database and schema.

Let us look at the multi-tenant architecture diagram below. Everything inside the orange ring is multi-tenancy. So, as long as tenants share the same software instance, it is multitenant. If tenants have the same instance, but different infrastructure, it’s physical segregation. For logical segregation, infrastructure is shared.

So, a shared schema means that the database and infrastructure are also shared. If a database is shared, then infrastructure is shared. Physical segregation means that all three are separate.

Physical segregation aims to combine the benefits of multi- and single-tenancy. It offers easier compliance and better security. But it is more cost-efficient than single-tenant software.

Look at the scale on the left. When tenants share more elements, costs and maintenance are better. But security, customization and compliance are worse.

In the case of logical segregation, companies can have separate or shared database instances. The former is usually an excellent compromise to get higher data security and a reasonable price.

🗃️ Multi-tenant database architecture

Now, let’s imagine that our tenants share a database instance. How does a multi-tenant architecture database work?

There are two types of databases – relational and NoSQL. In relational databases, the data of one or more tenants is organized in rows and columns. But sometimes developers cannot sort data like that. Then, they use NoSQL databases.

Relational multi-tenant DB architecture

Let us start with relational multi-tenancy database designs. Relational DBs include schemas. Those schemas have tables. And tables have rows and columns. You can see the illustration below.

Developers can separate tenant data on any of these levels. Isolating data of different companies is called data tenancy.

For example, tenants can have different schemas within a database. This multi-tenant database design is popular. If tenants share tables, these tables contain a column with tenant ID.

NoSQL database multi-tenancy

NoSQL databases contain documents and indexes. Documents are usually in JSON format. Databases scan all new data. This way, they understand what kind of information the data contains. They save information about it to indexes. In a way, indexes are like catalogs. They help databases to find all relevant data when it is needed.

In the case of multi-tenant data architecture, each document has a tenant ID. This way the system separates data from different companies. Additionally, developers can create separate indexes for different tenants.

Multi-tenancy types and single-tenancy: a comparison table

To summarize what we have learned, we have created a handy table. It compares the main multi-tenancy types with single-tenancy:

Silo, bridge & pool models

Different development teams use different terminology. Silo, bridge and pool models are popular terms. They explain the processes that we discussed but in other words.

Silo means that tenants have different infrastructure resources. For example, their data runs on separate virtual servers, they have different database instances, etc. This approach is also called physical segregation multi-tenancy.

The pool is the opposite. Here, tenants share everything from infrastructure to schemas. And the bridge model covers everything in between.

Some software owners use a hybrid approach. It is particularly popular for software with several subscription tiers. Thus, regular users can share resources under a pool or bridge model. But premium subscribers get a silo-level isolation.

🌐 Common SaaS Design Patterns

Here are several common design patterns that you should consider for your SaaS:

Multi-regional, Multi-Tenant Architecture in SaaS

Large SaaS providers often use a multi-region architecture approach. It can be implemented in different ways. Let’s consider the most popular one. Developers deploy and maintain several software copies. Each copy runs on servers located in a certain region. These servers can be a part of cloud infrastructure. For example, AWS has servers in many countries. You can choose where to host your software. Each software instance can support multiple tenants. Multi-region architecture can improve:

– Compliance,

For most companies, this is the main reason to use multi-regional architecture. As mentioned, many countries have strict rules protecting citizen data. So you can run different software copies in each region where your clients are located. Thus, users from the US can use the US version. Users from Germany or France – the EU version and so on. For example, Asana runs data of its EU users on AWS servers in Germany. And they have backups in Ireland.

Our team used a multi-regional strategy for one of our clients, Cayuse. This is a research management software. Most of their customers are universities and medical research facilities. Their clients come from Canada, the UK, the US and the EU. So they must follow strict government rules.

– Performance,

If your infrastructure is physically closer to you, the speed is faster. Better performance could be achieved by other means too. For example, by using AWS CloudFront. But this wouldn’t solve the compliance issue. So, in our case, better performance is a nice bonus.

– Resilience

Infrastructure in a certain region can stop working. Reasons can include natural disasters, like hurricanes or earthquakes. Another threat is a massive cyber-attack. With a multi-regional architecture, your clients will be less affected.

Microservices vs monolith architecture

Should you use microservices or a monolith approach? Well, for multi-tenancy cloud computing, we recommend microservices. Here are the main reasons:

– Scalability

Monolith architecture has some advantages. Often, it is faster and easier to build. But it has a huge downside – low scalability.

With microservices, you can easily expand the existing features or add new ones. And it is easy to add more capacities to handle new clients.

– Flexibility

Another benefit is higher flexibility. One can use different technologies for each microservice. So developers can choose the best tool for each situation.

– Resilience

In microservice architecture, software parts are less dependent on each other. So, even if one microservice fails, others will keep running.

🔎 5 Real-World Use Cases

Now, let’s look at several real-world examples of apps with multi-tenant architectures:

1. Salesforce: shared schemas, database partitioning

The Salesforce platform provides tools for customer management, sales and analytics. Their software has excellent scalability and performance.

All their tenants share the same database schemas and tables. Developers add a tenant ID to each record. This way Salesforce separates client data. They call this OrgID. Org is short for organization.

The company uses database partitioning to improve performance and scalability. This means dividing a large database into smaller segments. Such segments are easier to search and manage.

The company also addressed the “noisy neighbor” issue. They put limits to prevent tenants from using more resources than others.

2. DoorDash: separate databases, high compliance

DoorDash is a food delivery platform. It separates client data on the database level. The company has plans to expand internationally. And they chose this approach since it better aligns with the EU’s GDPR regulations.

3. Slack: shared schemas, high availability

Slack is a popular app for corporate communication. It uses multi-tenant cloud computing and logical segregation. They identify data owners using unique tenant IDs.

Slack regularly does data backups, to protect customer data from being lost. And they keep data copies in several locations to provide high availability.

4. Monday: multi-regional, compliance-focused

Monday is a popular project management solution. They switched to multi-regional architecture. Their primary goal was to improve privacy and compliance. Now they can serve clients from strictly regulated industries like banking and healthcare.

5. Jira and Confluence: micro-service, multi-regional

Atlassian provides popular cooperation software, including Jira and Confluence. These apps have microservice architecture. All requests to microservices contain tenant ID.

The company uses AWS and offers data residency. This means that the client's data stays in a certain region. Options include the EU, the US and Australia. And they have plans to extend this list.

Best Practices in Building Multi-Tenant SaaS Applications

Each app is unique. The success ultimately depends on how well it is designed. There 4 key aspects to consider when building multi-tenant SaaS:

• Scalability planning

Software architecture should be able to support horizontal scaling. This means adding more servers to handle more and more customers.

Analyze your target audience. Do they have stable traffic or are there peak times or seasonality? This will help you define requirements.

• Data isolation and security

Your software should include all key security measures. These are data encryption, authorization, authentication and access control. We also recommend regularly checking software for vulnerabilities.

• Performance and resource monitoring

Your app should be responsive and reliable. First, decide what KPIs you need. For example, what update percentage will you promise to your customers? What speed can they expect? Choose technologies accordingly. For example, AWS Autoscaling can help you rapidly scale resources as needed.

Monitoring your resource use is also important. Popular tools for this are AWS CloudWatch and New Relic.

• Automation and orchestration

For a SaaS app to be successful, it should have a strong CI/CD pipeline. This means that making updates should be easy. To improve this aspect, you can automate tasks and processes. Orchestration means automating groups of tasks to simplify a workflow.

📑🤝 Navigating SLAs in Multi-Tenant Architecture

SaaS must be reliable. Companies build work processes around it. And if such software stops working, its users can lose a lot of money. Here, SLA comes into play. SLA means service-level agreement. This is a legal agreement with your tenants. There, you list conditions of service.

Let’s look at an example. One of our clients, Volvo, provides trucks for delivery companies. The vehicles are powered by connectivity software. So, their clients can track their vehicle fleets in real-time. Volvo’s clients include industry leaders, such as DPD, FedEx and DHL. Downtime can potentially cost these companies millions of dollars. So, Volvo commits to high standards in their SLA, including:

– 99.9999999% uptime,

– requests processing in under 500 milliseconds.

You might not need to follow such strict standards. This heavily depends on your industry and target audience.

Implementing SLAs Effectively

To implement SLAs effectively, consider the following steps:

1. Research

Performance metrics should be a part of your market research. What do your competitors promise? What does your target audience need?

2. Offer several tiers

Perhaps some of your future clients prefer a lower price. Others might need a high performance. And they are ready to pay for it. So, offer both. You can introduce several subscription tiers with different SLAs and pricing.

3. Be clear

When you write your SLA, be sure to include all important metrics. These can differ depending on your business. But here are several common ones:

– uptime,

– availability,

– response time,

– error rate,

– throughput,

– latency, and

– capacity (storage space and bandwidth).

You should also include safety measures in your SLA.

4. Monitor compliance

Always track the system's performance. Make sure that you deliver on your promises.

Conclusion

Multi-tenant web apps are a cost-efficient way to serve many customers. They allow multiple companies to use the same software instance (copy). And their data doesn’t mix.

Compared to single-tenancy, multi-tenancy is cheaper to operate. You save money on infrastructure and labor. And your clients get a lower price. But there are several downsides too. Examples are lower customizability, security and compliance options.

Luckily, there are several types of multi-tenancy. Some of them tackle the mentioned challenges. For example, tenant’s data can be separated on a database level for better security.

Other aspects of software architecture matter too. For example, multi-regional deployment is excellent for compliance. It can ensure that a client’s data stays in their country or region. Microservices are also popular for cloud multi-tenant SaaS. They provide scalability, flexibility and resilience.

Examples of popular multi-tenant software are Salesforce, DoorDash, Slack and Jira.