SaaS Architectures. Single-tenant, Multi-tenant and Hybrid Architectures

April 29, 2023 • 27 minutes read

Software as a Service (SaaS) is a very popular software distribution model nowadays. At the same time, it is a complex architecture. Software engineers and business representatives may face a lot of difficulties with questions on how to build a SaaS distribution model. They may brainstorm about these questions on the planning, architecture design stage, before the start of the development

I can highlight some questions related to building SaaS that may help on architecture design stage:

• What architecture concept to choose between known SaaS concepts?
• How to build the most cost effective SaaS distribution model for your business?
• What type of data are you going to work with?
• What about data security?
• Do you need to cover any required regulatory compliance?
• Is it possible to automate the process of adding new tenants to your SaaS platform?
• How will you cover scalability within a grooving client base?
• How will you build fault tolerance infrastructure?

I am going to help you with these questions in this article. Let’s start with an overview of Architecture concepts for SaaS

There are 3 main concepts for building SaaS Architecture:

• Single-tenant Architecture
• Multi-tenant Architecture
• Hybrid Architecture

Who is Tenant? This is a client of your SaaS application. Depending on the domain of SaaS, it can be a standalone user, a company, a group of users representing one business. For example, if you are building SaaS as a CRM for business then a tenant of your SaaS is a company which will use your SaaS application. In case, if your SaaS is a file storage service for worldwide users than your tenant is a single user

Single-tenant Architecture

Single-tenant architecture is a concept when each customer or tenant has its own instance of the application and database running on a dedicated server. That’s quite a simple approach. In the simplest scenario your application is Monolith architecture with ability to change application settings for a specific tenant. Also it may be something more complex, like Event-driven architecture or even Microservices, but it should work within isolated compute resources only for one specific tenant. The simplest example of an isolated compute resource is one server for one tenant. That’s also the same codebase for every tenant, the same application. You may think about different features for different clients with some settings within the application. These settings may depend on specific needs or a specific subscription plan for a tenant

Advantages of Single-tenant Architecture

Customization

Single-tenant architecture opens great customization abilities. You are able to add and configure any software features for each customer's specific needs. Since each customer has their own isolated environment in isolated compute resources, they can configure it to their specific requirements without affecting other customers

Beta testing

With a single-tenant architecture you may release a new version of your application only for a specific group of your clients first. Watch how it works. Fix issues if any appears. Only after this release a new version for other clients

Scalability

Single-tenant architecture allows to scale compute resources of the application for each customer independently. This means that customers can easily increase the usage of the software without affecting other customers

Reliability

In case of any issues in software these issues may affect only one tenant but not all tenants of the whole SaaS platform. You may face some issues with performance for example. In this case only one tenant will have performance issues, but other will continue working fine within their compute resources in their isolated environments

Security

Single-tenant architecture provides enhanced security since each customer's data is isolated and protected from other customers. This is especially important for customers who deal with sensitive data or require high levels of security

Disadvantages of Single-tenant Architecture

Cost

Single-tenant architecture can be more expensive than multi-tenant architecture since each tenant requires their own server or a set of servers to run the software. Infrastructure may be very expensive. Such an approach may work for a tenant as a group of users (for example company), but may not work for a tenant as a single user

Maintenance

Single-tenant architecture requires more maintenance since each instance of the software needs to be managed separately. This can be a challenge in managing server infrastructure. Nowadays a lot of DevOps tools exist that may help a lot in automation. For example, a combination of Terraform and Ansible may help with initial tenant setup and further updates. Anyway such approach requires knowledge in this area, time effort in automation and further support

Multi-tenant Architecture

Multi-tenant architecture is a concept when multiple customers share the same application within the shared compute resources. In the simplest scenario it may be a single server. In a more realistic scenario it would be a cluster (scalable pool of servers). This architecture is more efficient and cost-effective than single-tenant architecture, but it may not provide the same level of customization or control. What about database? How do multiple tenants store data within the shared compute resources? There are 2 options:

• Separate databases for each tenant
• Shared database for all tenants

Multi-tenant Architecture with separate Databases

You can use a separate database for each tenant of your application. Even with the same codebase, within a shared compute resources, each tenant has its own isolated data storage. That makes sense if the tenant of your application is a group of users. For example, a company. In practice, after authorization, when we know who is using the SaaS platform we can work with a specific database connection for a specific tenant.

Such an approach doesn’t make any sense for scenarios when a tenant of your SaaS platform is a single user. Probably, creating a separate database for each single user would be over engineering with over price for the infrastructure

Multi-tenant Architecture with a shared Database

Such an approach makes sense when you provide your SaaS application to multiple single users where each user is a single tenant of the system. Think about a scenario when you provide a SaaS platform as a worldwide service for any user in the world. In this case you would probably use one database for the whole system.

In such an approach, the database is the most tricky part. Why? Because of scalability. The running backend side business logic can be scaled much more easily than the database. You have to think about database scalability. That’s become a tricky topic when it touches replications, sharding, multi region data storage.

It is also possible to use a one shared database for multiple companies, but it adds an extra level of complexity in business logic in your application, makes complexity in database structure, and gives a concern about security. What will happen, in case of just one mistake in business logic, when a user from company Y will see data from company X? Just think about this.

Advantages of Multi-tenant Architecture

Cost-effective

The infrastructure of the application is shared among multiple tenants, resulting in significant cost savings. That’s the more effective way of compute resource usage than with single-tenant architecture

Scalability

Multi-tenant architecture makes it easy to scale the application to meet the needs of all tenants. New tenants can be added without any major changes to the application. With the right Multi-tenant architecture you don’t need to start a new server for a new tenant. The best way to build scalability in Multi-tenant architecture is to use auto scaling features. For example, with technologies like Kubernetes, Amazon ECS, you can use auto scaling features which will help you to cover demand on your SaaS platform at any time. Do you have high traffic? No problem, autoscaling will increase compute resources. Is it inactivity time? No problem, autoscaling will reduce compute resources. This way you will get a fault tolerance application with effective compute resource usage. You will pay only for what you are using

Easy maintenance

With a single instance/cluster of the application serving multiple tenants, maintenance and upgrades are much easier to manage and implement. You will update the whole application for all tenants at a time

Disadvantages of Multi-tenant Architecture

Customization challenges

Multiple tenants are using the same instance of the application. This way customization can be challenging. Customizations that are specific to one tenant may not be compatible with the needs of other tenants. You have to think and build generic functionality which fits all tenants. Sometimes it may be difficult and you should be ready for compromises

Performance issues

If one tenant's usage of the application is particularly high, it can impact the performance of the application for other tenants

Security concerns

Multi-tenant architecture may open potential vulnerability to data. As everything works in one instance within one application there may be some data breach. One tenant may access data of another tenant. This may happen in case of a mistake in business logic or incorrect permissions. They may happen or may not. A lot depends on your architecture and development team

Updates

On the one hand, Multi-tenant architecture provides an easy way of updates, but on the other hand you are limited with beta testing and you have higher risk to release something new and unstable for all users of your SaaS platform. In other words, you are less flexible. If you update something then you will update it for everyone

Hybrid Architecture

Be flexible. Think about business needs. What works better for your specific business case? All described approaches may not work for your case in exactly the same way. You have to think about all aspects and cover business requirements. I will share some examples for better understanding.

In-house data storage

Let’s imagine you have built a SaaS platform with a single-tenant architecture on Amazon Web Services. You have some satisfied clients, but some of them can’t use your perfect SaaS product. It perfectly covers their needs, but they can’t use it because of compliances. They have to store all data in-house (on premises). In this case, think about some changes in business logic related to configuration. Technically it’s possible. You can discuss with your potential clients ways to go. For example, some parts of the application can be hosted on-premises while others are hosted in the cloud. For example, host database in-house and server with all backend business logic in the cloud. Backend does not store any data, all data stored in the database. This may fit regulatory compliances. This architecture would be suitable for companies that want to keep data in-house for security reasons but also want to take advantage of the scalability and flexibility of cloud-based solutions

Serverless Application

Let’s imagine another example. All described approaches use databases. What if you want to build a SaaS platform as a file convert service in the cloud? Users will use your service right away to convert files from one format to another. You can build all business logic on Functions as a Service (FaaS) with services like AWS Lambda, Google Cloud Functions, Microsoft Azure Functions, etc. The workflow may look like this:

1. User uploads file
2. User selects format to convert
3. User waits for conversion
4. Download converted file

Probably you don’t need a database in this case. You would use cloud storage to store files. In case you need a database just for authorization, to store user profile, track user subscription plan, etc. No problem, you can use some third-party services, like Auth0 and still be without a database. The same application for all tenants, the same business logic, scalability

Conclusions

The choice of SaaS architecture depends on the specific needs of the business, such as scalability, customization, security, regulations, etc.

Overall, single-tenant architecture can provide greater customization and security, but comes at a higher cost and maintenance complexity. It may be a good fit for organizations with high security or customization requirements, but may not be feasible for single users. Multi-tenant architecture can be a cost effective scalable way to provide software services to multiple customers, but may have less flexibility than single-tenant architecture.

All possible approaches require careful planning and architecture design to avoid potential issues in the future