Building Application with multi-tenancy capability
Is your application/PAAS/SAAS is affected are degraded in the performance due to activity of one single customer account/user-groups? If the answer is yes then probably your application/PAAS/SAAS has some multi-tenancy problem or lack of multi-tenancy support.
What is Multi-tenancy?
Multi-tenancy is an architecture which ensures application/PAAS/SAAS that each customer accounts or user-groups are given fair chances and resource to process their request all the time. Anytime anyone customer activity or usage pattern should not create any impact on other customers ability or fair share of request processing capacity in the application/PAAS/SAAS.
Why Multi-tenancy?
During all time Multi-tenancy architecture enables applications/PAAS/SAAS to ensure fair share of resource processing capacity at each layer for each customer account or user groups.
It enables software to be more:
How to build Multi-tenancy?
To implement multi-tenancy, we can break applications in two categories based on request processing types.
Application with Synchronous Request Processing:
In this category of applications, multi-tenancy implementation is comparatively easy. We can build rate limiting capabilities at the api/layer where customer or user groups request first lands into the application. This will ensure that no one account or user group can consume all the application resources and processing capacity.
Although at database layer it can get tricky because of not properly indexed or partitioned data. A big query (not optimized one) can impact the database performance for other accounts or user groups. That’s why, it’s important to think about multi-tenancy at each request processing layer including database. Ensure that database queries are properly optimized and all other dependencies are also optimized.
Applications with Asynchronous Request Processing:
It’s little more challenging to implement multi-tenancy in this category of application because once we put messages to some queuing system then the guarantee of giving fair share of request processing capacity to each customer account or user group is a difficult task to achieve.
Queues will process request one by one and if in the case one customer account or user group has sent thousands of requests then other accounts request is not started to process until and unless all the earlier requests are not processed.
The most ideal solution requires each customer account or customer group it’s own queues and consumers. So that requests sent by some other accounts or user groups are not blocked by any other customer account or user group requests. Although having a separate queue for each customer account or user group can be really cumbersome to manage.
Another way is having large number of partition and enqueuing requests by requestID or customer account or customer user groups as partition key can help to achieve some middle ground in terms of multi-tenancy and complexity but still it’s not a true multi-tenant application.
Each one of the above alternative mechanism has some tradeoffs, queuing message by requestId as partition key will not give you any ordered processing guarantee. Two requests sent in an order e.g request 1 sent earlier than request 2 can be processed randomly meaning it’s possible request 2 is processed first and then request 1 is processed by application.