Building Multi-Tenant Solutions for SaaS Applications — Part 1
Tenant isolation pattern in multi-tenant architecture
In this blog post, I will try to dive into how we transitioned to robust multi-tenant data architecture to handle the needs of multiple customers, or tenants.
In multi-tenant architecture, Isolating tenant data is the fundamental construct for SaaS applications. It goes beyond from the filtering of data at the database end by adding a tenant id. Main challenge in modelling multi-tenant data model is how to manage the configuration, resources, cross-tenant data access at functional level and also consider non-functional aspects such as scalability, security risks, performance etc.
Partitioning Models
To shape the SaaS applications, there are different variety of architectural models in SaaS environment. Each partitioning model associates with approach to managing, accessing, and separating tenant data. These are broadly falls into one of these three categories — Silo, Pool and Bridge.
The silo data partitioning refers to a model where tenant’s data is fully isolated from any other tenant data. Or perhaps, In terms of storage resources, tenant has separate database for each tenant.
The pool model refers to a multi-tenant model where tenants share all of the system’s storage resources and constructs.
The Bridge model takes a hybrid approach by moving all of the tenant’s data into a single database, while still allowing some degree of resource sharing and separation for each tenant.
It is often varies micro-service by micro-service as to which data partitioning model is right fit for them. The common influencers are compliance & security, cost efficiency, noisy neighbour, performance, operational agility etc.
Isolating Tenant Data
A robust architecture design must ensures the constructs are in-place that ensures each tenant’s resources have been logically and effectively isolated.
Isolation through Silo Model — To achieve the fundamental isolation goal of silo model, we must define clear boundaries, or separation between each tenant’s data. In relational data environment, this typically means to create a separate database for each tenant within a single cluster.
Isolation through Pool Model — To achieve isolation in pool model requires to have all tenants share the same set of tables and database within a cluster.
Isolation through Bridge Model — In bridge, we choose to have mixed mode by relaxing some of the isolation requirements needed of silo model. This usually means to have multiple tenants share the same database but with per tenant tables, or per tenant schemas.
Provisioning a new tenant
Once we provisioned the tenant, we can flow, or inject the tenant context in our micro-service as well as service-to-service communication and use these tenant scoped token for interaction with resources. This is a vital concept for a good SaaS design by making systems multi-tenant aware.
Fundamental challenge of pool-based isolation
Imagine we have micro-services running in same process space, and processing multiple tenants side by side, touching some data in the database.
How will we ensure that each tenant is prevented to gain access to another tenant’s data ?
The main fret is if whether or not the tenants are accessing the data in their tenant context which belongs to their tenant identity.
With the data stored in the same database, the possibility of crossing the tenant boundary may permanently damage the brand reputation and trust, also can lead to potentially unrecoverable event.
Runtime tenant-scoped access to data
To eliminate cross tenant access, we must create policies that scope access to the system’s resource for every data access for that tenant.
PostgreSQL 9.5 and newer includes a feature called Row Level Security, RLS. When we define security policies on a table, these policies restrict which rows in that table are returned or affected by SQL commands.
Takeaways
- Isolating tenant data is fundamental key in a multi-tenant environment.
- It is service by service decision as to which isolation model is right fit.
- Factor scale, operational agility, cost efficiency and security as key parameters to isolation strategy.
- Minimize developer awareness of multi-tenant policies.
