Multi-tenancy - A different perspective on software engineering principles

Let’s say you are getting ready to release your new hot project that’s been in development for some time. You’ve spent enough time and money on development and marketing, so you keep your fingers crossed that it really pays off and that potential clients are non-stop refreshing their mail for that BUY NOW/SUBSCRIBE email. But this is reality and in a good scenario, you get 3 clients the first week – clients A, B and C.

Client A doesn’t need that “awesome” feature that you spent 50 hours implementing it, client B wants that feature + some sub-feature and client C doesn’t even care it exists. You need to customize every instance separately or even worse – make a mess out of the code with special scenarios for certain clients.
Time goes by and you get up to 50 clients – 50 separate instances of the application. Around that time, one of your developers finds a critical bug that needs to be fixed ASAP and update every client in order not to break their system.
So deploy to 50 clients 1 by 1 ? Schedule a downtime for every client instance separately? It is enough to take one’s time and happiness – developer and client wise.

That’s where multi-tenancy architecture comes into play.

What is multi-tenancy? A software architecture in which a single instance of software runs on a server and serves multiple tenants. A tenant is a group of users who share a common access with specific privileges to the software instance. With a multi-tenant architecture, a software application is designed to provide every tenant a dedicated share of the instance — including its data, configuration, user management, tenant individual functionality and non-functional properties. Say goodbye to deploying to countless client instances 1 by 1 and customization of every tenant is easier than ever.
BUT, as everything else, multi-tenancy also has some pros and some cons. Some of the flaws of this architecture which I like to point out:

• Safety of the data is always a concern - all data is in the same place

• If the number of clients (tenants) grow and unless you are ready to have another server instance you might have an overcrowding problem. In other words - performance issues.

• If any accident happens (power outage, flooding) – all the tenants feel the consequences – downtime for everyone.

But as any other new technology - the weight of the pros is far more exciting than the fear of the cons. I had recently started working on new project with Laravel and VueJS on top of MySQL database. I used the hyn/multi-tenancy package for Laravel which setup went pretty smoothly. Must be noted that for me - generating a new tenant (instance if it was a single tenant application), migrating and seeding the tables, customize modules for certain clients and many more steps which would be mechanical hell in a single tenant application - are easier than ever. So if you found yourself in any of the above scenarios, I suggest you give multi-tenancy a shot and I wish you luck into exploration and experimenting with this architecture.