Multi-Tenancy vs Single-Tenancy:
Simplifying System Design
There are countless debates about monoliths and microservices. Let’s go one better and examine multi-tenancy vs single-tenancy systems. Can give a completely different perspective on the complexity or scalability of a system.
Imagine building your solution for just one customer. No worries about how many thousands of customers need to be supported. What would you do differently? How much simpler would the result be in the end?
If you think about multi-client capability, the entire system must automatically be able to handle multiple customers. But examine your requirements very carefully. It can often be so much easier.
A concrete example:
We had built a specialized service that had no idea how to compartmentalize data. For its purposes, it worked on an immense database and was unable to differentiate between different customers.
This was followed by the requirement to support multiple customers and delimit the data. Typically, you immediately come up with the idea of completely expanding your solution to include this option. An enormous effort and scalability must be guaranteed independently.
A solution that was almost too simple looked like this: A small proxy service was developed that was simply put in front of the customer instances. Each customer’s own services were set up and performed completely independently of each other. Performance aspects could be solved individually.
Now this was not a system with thousands of customers. But it still shows that a simple solution can often have an advantage over the academic one.
Check the specific requirements. Always keep it simple but expandable. And don’t invest unnecessary energy in a solution that’s too complex.