Introduction to Multi-Tenant Architecture

What is multi-tenancy?

Before we dive deeper into more complicated and technical stuff, let’s start our multi tenanting adventure with a little metaphor to better understand the general idea behind it.

Imagine an ambitious shepherd who has decided to start their own sheep-keeping business.

After obtaining the necessary funding and buying a large pasture, the shepherd intends to rent it to other sheep owners.

Due to the clever marketing strategy and smart business plan, in a fairly short period of time, the shepherd ends up having hundreds of sheep from various owners.

As the business grows, the shepherd becomes a serious entrepreneur. Ultimately, new challenges keep arising.

How does the shepherd quickly and efficiently figure out which owner a given sheep belongs to?

How does the shepherd manage and maintain the barn in order to know exactly where specific sheep are located?

The main aim of a multi-tenant environment is to solve these problems inside large data centers and SaaS applications.

The general idea behind it is that multi-tenancy is a type of software and database management architecture in which a single software instance can serve multiple users.

One option is to install single-tenant software or an operating system on individual machines, such as employees’ desktops or dedicated server machines.

A much more advantageous idea is the multi-tenant approach. It allows developers and Sysadmins to leverage available computing resources more effectively.

Even though tenants share the same hardware, in most cases they do not impact each other. Their data is kept completely separately, similarly to a separate virtual machine.

Each customer shares a single instance of a software application and a single database. Still, all of their data is secure and kept inaccessible to other tenants.

In recent years, the multi-tenancy approach to cloud computing is becoming more and more prevalent among the biggest tech companies such as Amazon Web Services, Microsoft Azure, and Google Cloud.

Multi-tenancy also plays an equally important role in SaaS applications. In this series of articles, we will focus on the last one.

If you are looking for support in the process of implementing a multi-tenant architecture to your SaaS applications – let us know. In Stratoflow we specialize in helping businesses in building high-performance and scalable systems every day. Let’s get in touch.

When to use single-tenant vs. multi-tenant architecture

Single-tenant

To better understand the mechanism of a multi-tenant application, it is necessary to start with understanding the differences between the single-tenant and multi-tenant software models.

In both cases, the end-user of said service is the so-called ‘tenant.’

The main difference between these two approaches is the fact that in the first one there are multiple instances of software serving customers and in the second only one, serving all of them.

Single-tenant architecture can be defined as a program that serves only one customer with a dedicated instance of a single software.

In this approach, the applications are installed locally and only some degree of user interface customization is permitted. Beyond that, there is no way of accessing the underlying code.

Main advantages of single-tenancy architecture:

• Dependability: Running the software locally does not affect the performance of other tenants.
• Security: Locally installed software can provide an environment less prone to data leaks and attacks.
• Local Management: The end-user has complete control over the settings of the installed software.

Despite these advantages, the single-tenant system has its fundamental limitations for cloud services, namely high costs and scalability problems.

A separate environment for each tenant can be quite expensive to run, especially taking into consideration their complex setup and the overall number of users depending on the system.

Moreover, in the single tenancy model, server performance must be able to handle both, the system itself and also the maximum load resulting from the user activity.

That means that each server machine must be as good as the maximum load that can be generated by its clients.

The main drawbacks of single-tenant systems include:

• Management and maintenance: Because the end-user is responsible for updates, the overall maintenance is much more cumbersome.
• Resources: With a dedicated software instance, the hardware could be underutilized.
• Setup: The setup process can be much more difficult due to a larger learning curve and delays because of individual installs.

[Read also: Web Application Development: Your Must-Have Guide]

Multi-tenant

Because of these drawbacks, multi-tenant solutions are much more convenient, future-proof and expansible for large cloud-based systems and SaaS applications.

Even for smaller companies, such an approach could also be beneficial because of smaller hardware requirements and a smoother onboarding process.

The benefits offered by multi-tenant hosting to end-users include:

• Better usage of resources: By sharing machines among multiple users and using the same infrastructure, available computing resources can be optimized.
• Lower costs: Thanks to hardware usage optimization and no need for dedicated infrastructure for each tenant, a data center can offer its services to customers at a much lower price due to lower operational costs.
• Streamlining release: Instead of installing new versions separately on each client’s desktops and servers, the multi-tenant package only needs to be installed on a single server.

One application server and multiple customers — a challenge for SaaS

SaaS stands for Software as a Service. This is a method of distributing software that typically involves a subscription model to access a product, tool, or service.

SaaS companies provide solutions that are mainly built on two types of architectures: multi-instance and multi-tenant which can be often confused with one another.

In the case of the multi-instance approach, the software is installed on the developer’s hardware. It is the developer’s responsibility to maintain it. Users have the access to multiple applications purchased through cloud systems.

However, it should be remembered that in this SaaS model, a separate instance is still created for each tenant on a dedicated server with their own database.

A multi-tenant SaaS system is an environment in which a single instance of the software that is running on an application serves multiple clients at the same time. Each customer shares an underlying software instance and a single database, but each tenant’s data is isolated and remains invisible to other users.

Some examples of SaaS multi-tenant applications include:

• Salesforce,
• Netflix,
• Zendesk,
• HubSpot.

So which one to choose when developing SaaS products?

If a SaaS provider has little time to develop and release the final solution, it would be much better to focus on multi-tenant architecture.

The development process is faster, and this choice provides more profitable options when it comes to future scalability.

If you want to learn how to scale, allocate and process data in multi-tenant architecture, check this article: Scalability, allocation, and processing of data for multitenancy.

Databases for multiple clients

As mentioned before, since it is a very broad category, multi-tenancy can be analyzed on various levels, from an application standpoint all the way to database management.

In this introductory post, we are going to focus on the latter.

Types of a multi-tenant database

When covering different approaches to multi-tenant data storage systems, we can once again go back to our shepherd analogy.

When building a barn for all of their clients’ sheep to keep them safe, the shepherd can do it in a couple of different ways.

They can build multiple, smaller barns dedicated solely to specific sheep or set up separate boxes inside a single much larger one.

Every approach comes with its own set of drawbacks and opportunities.

It is our shepherd that has to make a careful and informed decision to expand the business.

In the IT world, we can differentiate between three main types of multi-tenant databases.

And just like different barn projects that our shepherd has at their disposal, each of them has its pros and cons and works better in different business scenarios.

Which approach will work best depends entirely on your objectives and needs for your specific use case.

Below, we are taking a closer look at each of them.

Check our Case Studies.

Type 1: Shared database

Let’s say that our shepherd decided to cut some costs and keep all of their clients’ sheep inside one large barn. In order not to confuse the sheep, each one was given a special collar with a tag containing information about its owner.

This is pretty much how the first type of multi-tenant database works.

This type is called the shared data storage approach.

It distributes users’ data across multiple databases (shards), with all the data for a particular tenant being contained in a single shard.

A sharding key/tenant identifier is managed and imposed by the shared database schema (the logically separated area inside the main database).

All the data about sheep managed by our shepherd is kept in one large chart, and to determine who the owner of any particular sheep is we add an additional column with a special identifier. Usually, it is called Tenant ID.

To count the number of sheep in our shepherd’s database of this type, we could use such function:

Select count (*) from Sheep where tenant_id=1

In this particular multi tenant architecture example, the result of this function would be 2, because there are two Sheep with ID=1.

Designing a software architecture that serves multiple tenants can be challenging due to the need to maintain a complex mapping between users and databases in more robust systems.

Additionally, the application has to maintain a complete catalog of the shards and respective users.

Advantages of the shared database in multi-tenancy

• There is only one database schema to maintain,
• Fairly simple schema update rollout process,
• Simple user management — the process of adding new users is easy in comparison to other types,
• Easy start — there is one simple and fairly straightforward process of implementing such a system,
• Limited complexity — single schema means that there is a single database instance to connect to,
• Easy data accessibility — it is easier to determine such information like the number of entries or clients in the whole database.

Disadvantages of a shared database in multi-tenancy

• Increased security risks by unintentionally exposing user’s data or updating the wrong user’s data,
• Lack of ability to easily restore a single user data,
• Limited scalability — you can only scale-up hardware, rather than scaling out,
• Risks concerning compliance — in some cases there are law restrictions regarding where certain types of data can be stored.
• Probability of “noisy neighbors” effect — tenants can visibly impact the overall performance of multiple customers because of the lack of physical isolation between them,
• One-size-fits-all approach — tenants’ data volumes and usage can vary dramatically, making it more difficult to plan out efficient resource usage.

Type 2: One schema per tenant

In this scenario, our shepherd decided to still keep all of their sheep inside one large barn, but also set up separate boxes dedicated solely for sheep belonging to each owner. By doing so, sheep do not have to wear uncomfortable collars with tags.

Therefore, the overall management of their sheep-keeping business can be greatly simplified as sheep are more separated.

This is the bare-bone explanation of the second type of database architecture in the multi-tenancy approach.

In this type of data store infrastructure, we create multiple schemas in the same database to provide some level of data isolation to the users.

Schema is a logically separated area inside the database, inside of which you can name subdirectories with tables containing the user’s data. The tables in the schema view each other with the tables in the main schema.

At runtime, depending on the criteria to resolve, requests are redirected to the specific schema.

There is one database instance to hold the data for all tenants. Still, there are separate tables for each client, and each of them is set under a tenant-specific schema.

Referring once again to our analogy, if our shepherd wants to count how many sheep belong to a certain user they could use this formula:

Select count (*) from schema_tenant_3.sheep

In this case, there is no need for creating an additional column with the Tenant ID, because if a table is included in a certain schema it gives us direct information about its owner.

Advantages of one schema per tenant

• Data isolation — tenant data is more isolated, but is still within the same database increasing overall system security in the process,
• The reduced security risk of missing a WHERE clause to limit to specific tenant’s data,
• Data is partitioned into smaller tables, with smaller indexes,
• Optimizations could be made at an individual tenant’s schema level.

Disadvantages of one schema per tenant

• Present risk of querying the incorrect schema (e.g., specifying the schema for an object when it should have instead come from the tenant account’s default schema – the best workaround is including specific schema prefixes, which can feel unnatural for developers),
• Schema updates can be more involving, needing to be rolled out to several tenants,
• Lack of ability to easily restore a single tenant’s data (although it is a slightly better process than the first type due to logical isolation of tenant data),
• Limited to scaling-up hardware, rather than scaling out the system,
• Present although the somewhat limited risk of “noisy neighbors”.

Read also: An In-Depth Guide to Machine Learning Recommendation Engines.

Type 3: One database per tenant

By choosing the third option, our shepherd decided to build smaller, separate barns dedicated to sheep belonging to each user.

This approach could be especially beneficial in situations when one type of sheep is behaving with hostility towards others and when new clients come.

Then, it could be easier for our ambitious herdsman entrepreneur to expand the business.

On the other hand, it could also cause problems with the overall management and maintenance of the barn infrastructure.

As our analogy implies, in the third type of multi-tenancy database, each user has their own, dedicated database. Every time a new tenant is added to the system, a new database is generated.

Inside the main server, we have separate databases dedicated solely to specific tenants.

Similarly to the separate barns dedicated for each sheep owner, in each of them, there are different sets of tables. This solution provides the highest level of data security out of these three types.

Using this approach it is not necessary to add the Tenant ID table, because of the fact that the name of the database itself tells us who owns it.

As in case of the previous two approaches, to count the number of sheep we would use such formula:

db_tenant_3_SELECT_COUNT(*) from_sheep

Advantages of one database per tenant

• The highest level of tenant isolation and data security – data remains invisible to other users,
• Maintenance and development jobs are simplified,
• Can easily manage specific user’s data,
• No unnecessary query complexity,
• Reduced client responsibility,
• Cloud environments can scale out and scale up because tenants can be spread over multiple servers,
• Cloud service providers can balance costs by choosing between higher tenant density and server performance according to client needs and expectations,
• “Noisy neighbor” risk is minimized.

Disadvantages of one database per tenant

• Potentially more servers to patch and maintain,
• Adding new tenants is more cumbersome, as new schemas need to be created and set up,
• As the number of tenants grows, there will be more databases being created leading to potential problems with internal management,
• Maintain a registry of tenant-db mappings code can lead to added complexity,
• Application data shared by all tenants (i.e., dictionaries) in this type of multi-tenant system must be duplicated in each database or need to be extracted to another one that will be used by all tenants.

Why does multi-tenant architecture matter?

Multi-tenant architecture is the main technology that fuels modern cloud computing. It is actively used by almost all public and private clouds.

Multi-tenant architecture makes cloud computing economically and technologically feasible by allowing a large number of customers to leverage shared infrastructure and use the same application instance.

As we have already mentioned, the other crucial advantage of multi-tenant architecture is that it enables high levels of scalability. Private cloud providers can expand service to customers much faster because a single platform can serve multiple tenants.

Businesses can migrate their aging data centers to the cloud, gaining access to more computing power and an impressive array of cloud-based tools.

Such cloud deployments are only possible because multi-tenancy is a powerful and robust architecture that can deal with a great amount of data effectively.

Multi-tenancy also enables companies to build advanced hybrid cloud systems, which we are going to cover in the next article of this series of blog posts.

Summary

To sum it all up, multi-tenancy is a system that enables many customers to have common access to the same servers and software instances, but have their data separated for a higher level of security.

Just like a smart shepherd expanding the scope of the business, SaaS application architects or software development companies have different options when it comes to managing user data. The decision about which type to use should be made after a careful analysis of the pros and cons of each of them.

Because of its role in modern cloud infrastructure and interesting possibilities for SaaS applications, it could be immensely beneficial for medium and large companies having to store data belonging to thousands of clients. In such case, it’s high time to choose the best multi-tenant cloud solution.

Did you find this article useful? Don’t forget to share it!

We are Stratoflow, a custom software development company. We firmly believe that software craftsmanship, collaboration and effective communication is key in delivering complex software projects. This allows us to build advanced high-performance Java applications capable of processing vast amounts of data in a short time. We also provide our clients with an option to outsource and hire Java developers to extend their teams with experienced professionals. As a result, the solutions designed for our customers contribute to their business development. We specialize in travel software, ecommerce software, and fintech software development. In addition, we are taking low-code to a new level with our Open-Source Low-Code Platform.