Multi-Tenant Architecture

Multi-Tenant Architecture

Multi-Tenant Architecture

With the growing popularity of AWS, Azure and other cloud based service providers Multi-Tenant applications are getting popular, multi-tenant means that a single resource like a database or S3 bucket serves multiple clients. Each client should be able to access his own data and each clients data should be isolated and invisible to other clients. Similarly Authentication and Authorization plays important role in a multi-tenant architecture, some of the famous authentication and authorisation framework and tools are, OKTA, AWS Cognito, and Azure Active Directory.

Difference between a Multi and Single Tenant Architecture:

1- Single Tenant App Design

Single tenant architecture is a simple app which is design by or for a single client, and are often specific to that client only, all the data models and business logic depends on the single client and data and logic isolation is integral part of the business logic, and doesn’t need to be changed for each client, have a look on the following diagram, as you can see that each application is specifically designed for a single tenant and has a single DB schema to store all the data which is related to one client only.

Single Tenant Architecture

2- Multi Tenant App Design:

Multi-tenant applications have unique security considerations when compared to single tenant applications, they act like a Software as a Service (SAAS) model, therefore multi-tenant applications must pay special attention to identity and tenant isolation, there are multiple conceptual designs for a multi tenant app, but almost all of them falls un the following 3 categories.

a) Single DB with Row Level Security (RLS) or Multi Tenant Table (MTT) style

In this model, we have a single database accommodating multiple client’s data with data isolation achieved by row level security, each record in database is linked by the tenent_id key so the application can uniquely identify which row is related to which particular client, this model is very efficient for scalability as well as its cost saving. The downside of this approach is that you would need to

Multi-Tenant Architecture

b) Single DB with different schema per tenant

In this model design, we can have a single Database (or Bucket) serve multiple tenants of different types having different schemas, thanks to some thanks to some document based databases like AWS DynamoDB or Mongo DB we can have separate schema per client within the same database. The issue with this approach is that the application still needs to support all business logic specific to each client, some clients might want SSO, some might need Multi-Factor authentication, some may have their own Active directory server and some might be using AWS cognito for authentication, plus the authorisation policies per tenant might be different.

Scalability and billing in this approach is also an issue, there could be a case when one tenant is only using 5% of the resource (Storage and Compute) while the other tenant is utilising the 50% of the resource, we need to scale each tenant according to its demand and then later bill them based on the utilisation.

Multi-tenant Architecture

c) Multiple Tenant with own DB

This is also called Account level isolation, in a multi tenant environment

Multiple Tenant Architecture

Some Key features in a multi-tenant application

The following features could be a deciding factors what kind of architecture your multi-tenant app would need, before you choose an architecture, you need to think about the following points, keep in mind that sometimes licensing and compliance is the only deciding factor, there are some businesses which just cant be allowed to run in a shared environment, for example Medical and HIPAA contracts might not be allowed to use in a shared environment, in that case you need a separate Multi-tenant model.

1- User Onboarding (Tenant Admin, Tenant User, Customer)

  • a) A multi-tenant organisation setup
  • b) Application
  • c) Directories
  • d) Users
  • e) Groups
  • f) Roles
  • g) Policies
  • h) User type (Tenant Admin, Tenant User, Customer)

2- Single Sign-on (Tenant Policies)

3- Adaptive MFA

4- Universal Directory

5- Lifecycle Management

6- API Access Management

7- Authorization

8- Authentication

9- User Management

10- B2B Integration

11- Workflows

12- Identity Engine

13- Devices

14- Directories

15- Social Login

16- Single Sign-on (SSO)

17- Multi-factor Authentication (MFA)

18- Storage (Database + Files)

19- Compute (Resources)

Lycore Pvt Ltd (lycore.com) is expert in building multi tenant apps with payments / payouts using Stripe and Plaid for all your necessary app architecture and coding from idea to application, so if you have an idea lets talk 🙂  

Related Posts