Multi-tenant SaaS Platform – Introduction


So, I was approached by a small group to help them create a Multi-tenant SaaS platform which will serve as a B2B solution in their area of business. Without wasting much time in the preface lets just try to jump into the real thing. There are many parts to such a platform. However, it would be wise to not assume that the readers know about all these terms. Here is a small explanation about the first line of the post.

B2B solution

A kind of business solution which is offered to businesses and not necessarily to end consumers. This also means that our customers would be businesses of all size. For e.g. Workday, a solution which is mostly required by businesses to process employees payroll.


This means that many businesses will be using the same platform. It can translate to many definitions and can result in different understandings. However, the minimal things which businesses will expect are:
  • White Labeling
  • Custom configurations
  • Domain names ( vs
  • Access to their data for ML and ... (put your favorite fancy buzz words here)

SaaS platform

SaaS means software-as-a-service. The general business model is to offer paid subscriptions to consumers to use your software. There can be various subscriptions terms (monthly, yearly, usage based etc). This also means that you as the service provider bear the cost of one time fees like (research & development) and recurring fees like (maintenance in all forms - infrastructure bills,  support, future development and many more) This model brings in a lot of complexity in the product design. Sounds stupid? Allow me to explain. There are few challenges with this kind of platform


  1. Freemium model -  most such businesses have to offer a free access to the platform for quite some time before you can start charging them money. Even Google and Microsoft are not discounted on this one.
  2. Legal Issues - In the era where everyone is happily throwing away their data on Social media, governments mandate certain data laws for businesses. This materializes into the following:
    1. Data isolation between regions.
    2. Physical boundaries for data.
    3. PII data protection.
    4. Auditing and storage for few decades and many more.
  3. Operational Issues - This surfaces when we have to deal with a lot of time zones. It is really difficult to get a window wide enough to carry maintenance without affecting customers.

Relation to Cost

So all the above points, add to the increased cost. Everyone is limited by budget, that is why the product has to be designed in a way so that we can avoid wastage of resources.
  • Think about the data isolation, which can increase number of separate databases. Design wisely so that data is already horizontally  partitioned (think about sharding). It will make your life easier when you have to separate that data in different databases.
  • Physical boundaries for processing would end up in VMs in different regions. This is less of an issue once data is separated, you can always start a new VM in the new region.
  • PII data protection would lead to encryption & secure storage (more processing time during retrieval - more CPU cost).
Knowing all these and operating under a strict budget will force you to think and improve the design.

The way forward

Having understood the primary challenges (complex requirements, minimum budget, flexibility for future development and many more), it became very important to decide on how we are gonna design the database and deployment architecture. These are the two things which will address the cost challenge of the solution. Of course being a small business, it is really hard to have our own infrastructure due to following reasons:
  • initial cost
  • lack of disaster recovery strategy
  • maintenance overhead
  • single point of failure
  • uncertainty about the product's future
Hence, the obvious choice was to use Infrastructure as a Service. The next section is heavily colored by my own opinion and experience, please don't consider it a general rule of thumb. There was absolutely no doubts in choosing AWS over Azure and Google for the following reasons:
  • AWS is more mature
  • Support is amazingly fast
  • Has cheaper plans and favors startups with 1 year free tier across most of its services
  • It has more than 100 out of the box services which integrate seamlessly
  • And of course experience in using AWS stack.
So, a decision to use AWS is already made. The next major decision is about Continuous Build and Integration (because no matter what product and architecture we will come up with, a software development project needs continuous build and integration). We will discuss more about this in the next post.   Thanks for your attention :)