Baking Multi Tenancy in SaaS

Multi-tenancy is a common requirement in any modern SaaS. The way a B2C SaaS will support it will vary greatly from a B2B SaaS. Also its implementation would vary greatly from use case to use case. A good architect would anyway define multi-tenancy support and the level of separation of concerns per tenant in the architecture right from the beginning. Building multi-tenancy later or as an after-thought is a recipe for unwarranted complications.

Multi-tenant Schema Options

A. Database per Tenant

B. Schema per Tenant

C. Records per Tenant

Other factors affecting multi-tenancy

• Authentication Methods
• Authorization Methods
• Security and Data Isolation requirements for each tenant.
• Load Balancing/Geo-Graphical distribution/Tenant Partitioning.

Security and Isolation requirements can demand a tenant's data be on completely separate databases or disks or may be across different instances or clouds. Sometimes it may require encryption of data using separate tenant keys. Tenant partitioning is another way of load balancing of geographically co-locating tenant database closer to them. Many reverse proxy server/gateways/routers to route API calls for a tenant to a particular geographically co-located microservice instance running nearby. There are myriad of ways you could partition this to achieve various architectural goals.

If you are using Spring Boot it provides a very excellent way to implement multi-tenant microservices in your SaaS by way of AbstractRoutingDataSource class. All your database queries can be routed to a data source pointed to by each tenant.

import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource



public class MultiTenantRoutingDataSource extends AbstractRoutingDataSource {
?
 ? @Override
? ? protected Object determineCurrentLookupKey() {

? ? ? ? return TenantContext.getTenant();
? ? ? ?
? ? }
};        

Another example of how Multi-Tenancy can be baked in a Spring Boot based Microservice.