Skip to main content

Deals You Can't Miss

1 Year Subscription

Multi-tenant Architectures

 


Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways:

  1. Separate Apps & Separate Databases
  2. Shared Apps & Shared Databases
  3. Separate Apps & Shared Databases
  4. Shared Apps & Separate Databases
There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making.

Separate Apps & Separate Databases

  • Easiest to implement from development and deployment stand-point.
  • Just automate the deployment infrastructure for every tenant for quick set-up.
  • Most expensive of all the models from infrastructure cost stand-point.
  • Relatively longer deployment time for newer application versions, at scale. 
  • More wastage from infrastructure resource utilization point of view.
  • The application's statelessness criteria for scalability would mean:
    • not holding user-request data
  • Suitability:
    • This is the best way to begin your SAAS platform until product-market fitment.
    • When you provide SAAS as white-labelled product.
    • When you deploy your SAAS product at client infrastructure, maybe for compliance reasons.
  • Challenges:
    • How do you optimize resources for cost?
    • Not succumbing to the temptation of having different code-bases for different tenants. Yielding to this temptation is like getting those easy financial loans at very high interest rates and with the notorious rider of terms and conditions, that is often overlooked blinded by dreams... just as in gambling houses. Often though, the gamblers here are the Product Management team and the losers that get publicly shamed are the development teams.

Shared Apps & Shared Databases

  • The most complex beast of all the multi-tenancy architectures. Depending on the magnitude of tech-debts and gap in the discipline of engineering management, the complexity often grows many-folds increasing the risks of product stability and scale.
  • Maximizing infra utilization every bit for maximum profitability. 
  • Challenges:  
    • How do you manage as volume of transactions  and data increases? The relational database by its virtue is vertically scalable and not horizontally scalable. Now this means it could become a bottleneck sooner than you think as you onboard more and more tenants, depending on the volume of transactions and data.
    • In case of SaaS apps that provides lot of customizations on the UI, how do you get this tenant specific configuration optimally for latency? Wix eCommerce, Shopify, etc.

Separate Apps & Shared Databases

  • A model where tenant specific configuration are tied to deployed instances, but all share a common database. The data isolation per client is achieved by prefixing database schema with tenant info. 
  • You got many web-frameworks and web-plugins supporting this model of prefixing-queries with tenant specific data, to hit the right datasource. For example, apartment (rails/ruby), multi-tenant (laravel/php), springboot (java), etc.
  • Relational database instances are expensive. It way pricier than your application instances and is not as disposable as your compute instances can are. You got to do a bit of forward looking into future for its capacity planning.
  • When you are managing your database instance as a SaaS provider and want to optimize on the overall cost, often the easiest thing to do is use shared database.
  • The application's statelessness criteria for scalability would mean:
    • not holding user-request data
    • not holding database-responses
  • Challenges: 
    • How do you manage as volume of transactions  and data increases? The relational database by its virtue is vertically scalable and not horizontally scalable. Now this means it could become a bottleneck sooner than you think as you onboard more and more tenants, depending on the volume of transactions and data.

Shared Apps & Separate Databases

  • A request can hit any of the available application instance.
  • Tenant specific configuration is got dynamically with every request.
  • The application's statelessness criteria for scalability would mean:
    • not holding user-request data
    • not holding tenant's configuration
    • not holding database-responses
  • Challenges: 
    • How do you hit the right database dynamically on a per request basis? How do you do it optimally for latency? Think  of Atlassian suite of products like Confluence, Jira, Bitbucket etc.
    • In case of SaaS apps that provides lot of customization on the UI, how do you get this tenant specific configuration optimally for latency? Wix eCommerce, Shopify, etc.

Hope that helps you in your design choice for your SAAS architecture...If your experience is otherwise from mine, or that you disagree with any of my points, do pour your thoughts and help me learn from your experience.

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou