Fundamentals of multi-tenant software

Let’s explore the fundamentals of building a multi-tenant software as a service (or SaaS) application. The design choices to consider and some of the benefits of multi-tenancy apps.

Multi-tenancy is an architectural tool. It’s a very powerful tool. You don’t have to use it, but you should know how. If you are going to build a good multi-tenant application, you should be doing so by knowing your choices, not by fluke.

The obvious benefit

Imagine you own a product based company that caters to one client. You could architect the product by listening to requirements from just this single client. But you will be missing out on several potential clients having similar needs. Why not build a single product that can cater to multiple clients, who differ little in their ways. By building a software as a service (or SaaS) application, that is multi-tenant—and delivered over the internet—there’s a lot to be gained.

A multi-tenant architecture is a preferred choice for building SaaS solutions. This allows us to maintain a single code base for all the clients. The client can be thought of as an organization which needs to service its own customers. These organizations are registered as tenants within the SaaS application. Building a single application that serves multiple clients—using the same hardware—will bring your company some benefits:

• Less number of support staff are required to keep the system up and running.
• The infrastructure itself could be hosted on Cloud that automates most management tasks.
• The SaaS business model allows you to have a predictable income: you can charge a recurring fee for the service provided to each tenant.
• All in all, you get reduced cost and better value for your investment.

But what about client benefits? They aren’t going to get sucked into your solution without any mutual benefit. And of course, they get some too! SaaS is an attractive alternative for clients who don’t want to:

• Pay a lump sum price for the one-time purchase of software.
• Set up and manage the on-premise data center or worry about licensing.
• Run updates and security patches—either on their own or from a hired help.

The SaaS provider manages security, performance, and high availability aspects. The client just needs an internet connection. But, of course, it’s not easy to build such a solution without investing some upfront effort. Although we spoke about what both parties stand to gain, there are challenges in building a SaaS solution.

Challenges and soutions

A major challenge is to provide tenant data isolation. In this kind of application, each client gets their own private data using one of the data isolation strategies—which we will look at shortly. Remember the client? that’s our tenant an organization or business that has its own customers—the end users that they are serving. We can’t have one tenant’s data get served to another. Another challenge is to meet the customization needs of each tenant. These may be UI, features, or business rules that can vary between tenants. Let’s peek into the strategies available to us to address some of these challenges.

Tenant isolation strategy

With every new paradigm shift comes new challenges, and multi-tenant architecture is no different. The traditional approach to building applications doesn’t meet the special needs of a multi-tenant application. Here we take a look at the fundamental data isolation choices, to improve the manageability of this kind of app.

In a true multi-tenant architecture the application or deployment is shared across tenants. There are three choices to consider for tenant isolation at the application layer:

Database per tenant vs Shared database shared schema

• DATABASE per tenant: A separate database server per tenant provides maximum data isolation, security, and scalability. But it adds to the maintenance cost: as each tenant would require their very own database. If you are managing 20 or 100s of tenants then you could start having administration nightmares. There are solutions to help manage this, but may not be worth the cost and effort.
• DISCRIMINATOR or shared database shared schema: Single database schema with tenant data partitioned using a discriminator column. This implies that each table will have a column containing a tenant identifier. Most folks tend to suggest this as a preferred choice. It’s probably the easiest to scale—if you haven’t guessed this already. It’s also the cheapest requiring one database server with a single database schema.
• SCHEMA per tenant: With this one, you use a single database with different schemas for the tenants. This is the in-between solution compared to the earlier two. Think shared database with separate schemas.

Each approach has its pros and cons which can be looked up in detail over the internet. Having worked with the DISCRIMINATOR option for a couple of my SaaS projects, I must admit, I wouldn’t recommend it for small or medium-sized companies. Although desirable for its economic benefits, there are some non-monetary costs to watch out for. Although the discriminator option can often be the cheapest to operate at scale, it adds complexity to the application layer. In this strategy, the application’s model and data access layer need to be multi-tenant aware to a greater degree than desired. Depending on certain compliance and security policies, co-hosting may not be an option—but your clients can demand this.

With the discriminator strategy, developers need to exercise caution when making code changes. Every SQL query, database view, and function has to be checked for tenant filters. A SaaS application arguably has a longer life expectancy than a traditional app. The original maintainers won’t be around forever, which makes changing this kind of code tricky, to put it mildly.

If you don’t have to support hundreds of active tenants (organizations with their own user base), then I would recommend choosing the in-between solution of a shared database with separate schema per tenant. This relieves you and your team from some of the pains we just went over. For both the database and schema strategy, each tenant would get their very own set of connections. This approach can be considered more secure vs the discriminator approach: data can be kept physically separate. There’s more to this decision but let me not keep you waiting. Just know, it’s not a choice to be made in haste.

Reference Multi-tenant application

:::info Here I have put together a sample yet real-world reference implementation of how one could build a SaaS multi-tenant solution.

We will cover:

• SaaS multi-tenant architecture fundamentals
• Tenant data isolation strategies
• Using JPA or Hibernate for multitenancy
• Using JSF Contracts for tenant-based UI customization
• Java EE Security for authentication and authorization
• Dockerization and using a reverse proxy like Traefik

Link - Coming Soon

:::