Microservice Architectures — Single Tenant or Multi-Tenant?

Simplified Microservice Architecture example of loosely coupled, cohesive services acting together.

Single Tenant. Multi-tenant. What is the difference?

When I explain this whole “tenant” application thing to people, I use what they are familiar with. A single tenant is a single family house detached from others. Only one family uses it. A multi-tenant application or service is more like a condo building or apartment building. There are multiple people sharing the building, the water pipes, the drains, the roof, etc. Regardless of what they pay for, they are using shared infrastructure for their housing.

Single Tenant MSA setup, each gets a copy of the microservice in their architecture.

Why would you use Multi-Tenant?

So the question comes up then, why use one over the other? There are a few reasons I can think of where you may choose a multi-tenant microservice in your architecture. One big one is resources. If you choose a single instance every time your microservice runs, you are duplicating resources (CPU, memory, cost) required to run your microservice. And if you have a separate database or database table, that is also duplicated. Anything that microservice uses to run is duplicated. So if you need to conserve any of those resources, you may want to use a multi-tenant design.

Multi-tenant services working to serve multiple MSAs in a single instance/cluster per microservice.

Where might you use Multi-Tenant?

I mentioned earlier, one place you may want to use multi-tenant could be logging. A similar place could be auditing. Put all your events into one spot and segment them inside the microservice/database by application. You can allow multiple tenants to use the system, and design the CRUD methods based on the application. You also can correlate information and view data across multiple applications all at one spot easier.

Where would you choose a Single Tenant approach?

On the flip side, there may be some very good reasons to choose a single tenant microservice architecture approach. Your design may segment your customers into their own clusters of servers for your MSA and they pay on the usage. It is easier to track and justify all costs if they are the only users of them in that particular design.

What are some of the design choices to discuss?

There are probably some questions, concerns, ideas and such floating through your head now if you are a developer, architect, or system administrator. There are probably a lot more if you are like my buddy Dave at Tutela who is a Cybersecurity and Information Security guru. I listed out a few below.

Where to go from here

I said from the outset my goal in this article is to get you and your team thinking on these things. And it is for me to write down while I have it in my head so I can revisit it later. I have used and reused my own posts time and time again to remind me what I did. Or to point out to others possibilities on doing their software engineering work. I just did this with an intern that had questions on Prometheus and Grafana. So yes, these are a little self serving . . . not going to apologize for that! :-)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dale Bingham

Dale Bingham

CEO of Soteria Software. Developer on OpenRMF. Software Geek by trade. Father of three daughters. Husband. Love new tech where it fits. Follow at @soteriasoft