Multitenancy and microservices

In this post, I want to give an example that will make it clear when to choose
microservices architecture.

Multitenancy

Multitenancy means that a software allows multiple customers to work on it
without having to worry about things like data sovereignty and performance
problems. What I mean by this is that if one user is causing too much load on
the servers, then other users should not feel it. Also corruption of the data
of one user should not corrupt the data of the other users on the system.

       Every user must feel that he is the only one logged

       in to the system at all points of time.

Microservices

Microservices is a hot term these days and everyone wants to jump in on this
bandwagon. Microservices is basically an architecture design pattern where a
suite of small independent services, which can be autonomously deployed without
affecting the other choreograph together to deliver the functionality to the
users. A key to achieving this is to keep the databases of the myriad of
individual services different.

Explosion of databases

If one has to maintain data sovereignty for the sake of multitenancy, each
user/customer must get his own separate database. Since each microservice has
its own database as well, soon we will have an explosion of the number of
databases that we will have in our system. If there are n customers and m
microservices, then the number of databases is n * m.

When to use microservices architecture

The above is just one example of how microservice introduces additional
complexity. Only when such problems are small compared to other problems that a
monolith faces, we should decide to use microservices architecture.

       Don't even consider Microservices unless you have

       a system that's too complex to manage as a monolith.

       - Martin Fowler