Architecting Multi-Tenant SaaS Application

Software as a Service (referred as SaaS here after) is a software distribution method where Tenant (Organization) can access software application over the Internet using a browser. The application is centrally hosted, managed and upgraded with new features automatically by the SaaS provider.

Depending on the Business model, SaaS provider can float different pricing models for the end users. Some of the typical pricing models are —

1. Pay per user/month or year, inclusive of all application features
2. Basic features free; pay for add-on features per user/month or year
3. Pay per user/month or year based on selected package (set of features) — Basic, Silver, Gold, Platinum, etc. (some of the standard packaging terms)
4. And many more…

Architecting a SaaS application, especially Multi-Tenant, needs some serious thinking around specific areas. This blog post covers some of the key areas which every Solution Architect should take care of when working on Multi-Tenant SaaS application. These areas will have an impact on the overall Application Architecture, Time to Market and Operational Overhead. Let’s dive in —

Area 1 — Tenant Data Partitioning

This is by far the most important area in Multi-Tenant application. How would you handle data of different Tenants? There is different partitioning strategy available to handle this and selection of the strategy is driven by the scalability, data isolation, performance, operational aspects and compliance requirements. Let’s look at the strategies —

Database Per Tenant — In this strategy, every Tenant has its own dedicated Database

Pros

1. This strategy ensures highest level of data isolation and safety as data of each tenant is stored on a different Database server.
2. Database operational aspects can be customized based on the Tenant need. Database backup timings, how long to keep back-up, data purging strategy are some of the tasks which can be customized based on Tenant’s requirement.
3. Restoration of data is also straightforward should there be a need to restore from the back-up.
4. From security perspective, if there is a need to encrypt data at rest while storing data in the Database, it can be achieved depending on Tenant’s requirement. If Tenant wants to provide its own encryption key, it can be configured as well.
5. Database query performance is dependent on Tenant data and is not affected by other Tenant’s data. It can further be tuned should there be a need.
6. Vertical scale should be easy until you hit the ceiling and want to explore other scaling options like Database Shard, etc.

Cons

1. Cost (just one word is enough 🙂). Yes, you have to pay per Database now.
2. Poor resource utilization. When on-boarding a new Tenant, provisioning of Database with right sizing is a tough call. You would always want to provision a bit higher configuration machine — as you don’t know the usage pattern yet. Off course, this can be guesstimated based on traffic pattern of other Tenants.
3. Database infrastructure needs to be managed — additional responsibility for the Ops team.
4. Database schema management gets complicated. For every new application release which has a Database schema change, the schema needs to be updated in all the Databases. Assuming hundreds of tenants, you have no option but to automate Schema upgrade, monitor the progress and handle the failures. This looks easy but let me tell you, this has taken systems down if not implemented properly.
5. The Application architecture gets a bit complicated as for every Database transaction, the 1st thing to be identified is Tenant’s Database. So, there is a lookup process. The lookup operation can be optimized and cached for faster execution.

Shared Schema Across All Tenants — In this strategy, there is a single Database instance with shared schema and tables created inside the schema is shared across all the Tenants

Every table created in the Database has a Tenant identifier column present.

Pros

1. Low cost.
2. Efficient Database server resource utilization.
3. Easy to implement. Application architecture in terms of Data persistence layer is straight forward. Just one Database to handle.
4. Database schema upgrade becomes easy.
5. Easy Database infrastructure management.

Cons

1. Tenant specific customizations in terms of Database operations not possible.
2. As data grows bigger, query performance could be hit. And this may require further tuning at Database level.
3. Can easily hit Vertical scaling limit on Database front as more and more Tenants are added in the system. There are ways to deal with it.
4. Should there be a need to restore the Tenant data to a specific point if the data gets corrupt, it adds another layer of complexity as data back-ups are done at the Database instance level as a whole and not for each Tenant data.
5. From implementation point of view — one has to be very sure that every Database transaction has a Tenant specific identifier added in the SQL query where clause, else it can leak data across Tenants.

Schema Per Tenant — In this strategy, there is a single Database instance at the Application layer, and a dedicated logical schema is created inside the Database instance for each Tenant

This is a Hybrid strategy — which takes the positives of both the approaches mentioned above.

Pros

1. Cost efficient.
2. High efficiency of Database server resources
3. Less Database server infrastructure management

Cons

1. Database operations in terms of back-up and restore is still not straight forward but at least improved as tenant schema can be restored as a whole.
2. Database schema management is still complicated.
3. The Application architecture still stays a bit complicated as for every Database transaction, the 1st thing to be identified is Tenant’s schema.

Area 2 — Accessing the SaaS application / Identifying the Tenant at Runtime

In a Multi-Tenant system, we all understand that all Tenants would access the same backend application. But when a request from a Tenant user hits the server, how does the backend server know request is coming for which Tenant?

It depends on how you allow the Tenant users to access the application. Are you going to create sub-domain per Tenant? Or there shall be a single domain for all the Tenants to access the application.

Which means, if there are 2 Tenants — ABC Corp. and XYZ Corp. onboarded to a SaaS Application (waswani.com), you can either provide —

abc.waswani.com sub-domain to ABC Corp.
xyz.waswani.com sub-domain to XYZ Corp.

OR

waswani.com to both ABC Corp. and XYZ Corp.

Well, it all depends on the Business Use Case you are trying to address with SaaS application.

With single domain, the solution becomes easy to implement. But this option can be implemented provided there is a mechanism to identity Tenant users based on some known pattern.

For example — if all users of a Tenant follow a standard username pattern, let’s say user@abc.com, for logging into the application, then Tenant can be identified based on the domain in the user name. But if such a thing cannot be enforced because of some reason, then you can implement below strategy —

Option 1 — Have a common Database table to store users across Tenants. This strategy will also force username can be same across Tenants. This strategy may or may not be OK as per Business and Compliance requirements.

Option 2 — Sub-domain per Tenant — A bit cleaner in terms of identifying the Tenant as every tenant will have its own sub-domain to access the application. But this brings additional complexity in terms of managing the sub-domains — CNAMEs to be created, managed against the DNS. Not easy!!!

Note — If the SaaS application offers B2B integration APIs, then there are other means available of identifying a Tenant. Not getting into that currently.

Area 3 — Security

This is one big area which can have books written on it. But a standard pattern is to funnel all the traffic through an API Gateway which can work in collaboration with a Centralized Authorization service to ensure —

1. Tenants are entitled to access only those features they are subscribed to
2. Role based access control for the Tenant Users. If it is a B2B SaaS application, then ensuring 3rd party client is allowed to call the APIs
3. Rate limiting and Throughput control — depending on the subscription and pricing model.
4. Blocking Tenants who are no more active in the system or are blocked
5. Whitelisting allowed IPs to access system
6. Many more… (yeah, this list will just go on 😏)

Working with Multi-Tenant systems needs to handle few other areas as well, for instance how to handle Tenant specific User Interface theme, handling security of data at CDN layer if that is used in the application. Will try to cover the left-over topics soon.

Till then. Cheers!!!