Multi-tenancy considerations of microservice designs

Many software vendors turn to software as a service – SaaS – to enable rapid scale. SaaS enables a new form of quick distribution and achieve economy of scale – as customers share the same code.

Separation of customers are referred as tenancy. Or simply multi-tenency.

Whilst multi-tenency pose a known domain, the emerging use of microservices are not often included in the design of multi-tenancy.

This article is to share a few considerations when dealing with the design principles of microservice use of multi tenancy.

Database strategies of multi tenancy

If you are not familiar with the different strategies of multi tenancy, here is a quick guide.

• Single database, same scheme. All tenants share the same database, and the same schema. Often tenants are isolated and identified by a TenantId column on every table with a referential constraint to a tenant table. In an e-commerce application, Order table and Customer table only exist once but seperates tenants by column.
• Single database, different schema. All tenants share the same database, however every tenant hold their own schema. Often tenants are also isolated and identified by a TenantId column on every table with a referential constraint to a tenant table. In an e-commerce application, Order table and Customer table only exist once but seperates tenants by column and seperates schema for data.
• Multi database. Each tenant hold their own database in a dedicated database. An e-commerce application would have multiple databases of the same schema by routing to each tenant using connection strings. This is the enterprise strategy of multi-tenancy.

Enter multi-tenant microservices

Microservices are the biggest buzz of the coding industry right now.

The concept of microservices define

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small units of people
• Single data domain

To enter the principal issues of this article, the latter element pose a new set of design considerations. In micro service designs, every service handle it owns data domain. This is a design fact. So how do you deal with multi-tenancy?

In our example of the e-commerce application, we would break our application into an OrderService and a CustomerService. Each will pose by providing their own data domain. If we apply the patterns of multi-tenancy you would quickly find that the simplicity of microservice designs apply a complexity to the structure.

Let’s examine:

• Single database, same scheme. The design principles of microservice prohibit this approach. Which the indicate that each service, would have a dedicated database with the same schema but seperated by a column for example. This approach would limit the number of databases, and keep data domains isolated per service. Yet we cannot accommodate individual requirements.
• Single database, different schema. As with the above every service would have its own data domain, providing a different schema seperated by a tenant isolator – often column. This also limits the number of databases.
• Multi database. Or database per tenant is the most secure and scalable design. However with the introduction of the microservice principles you would cater to a database design with one database per tenant, per service. That is a maintenance and deployment nightmare.

So when you start designing SaaS multi tenancy solutions in modern microservice environments you need to consider you element.

Edit — feedback from multiple conversations
The de-facto standard that each microservice require their own database, is a disputable standard in my opinion. I agree that each microservice should only have a scope of the domain model belonging to that service – and not be aware of the full data model. But in that perspective data model vs. domain is always two completely different things.

We have successfully implemented a microservice architecture on multi-tenancy by having a single database per tenants, a common data models across and isolating the domain knowledge per service.

Let me examplify:

· Data model. Given the example of an e-commerce site, we have a single database, with a table for Orders and a table for Payments. These tables are huge, full of relational data, and have foreign key relationships. Both Orders and Payments have data expanding product, customer and more.

· Domain and microservice isolation. Microservices are built to isolate their domain knowledge. Though we have the same database, and tables – the Payment microservice will only look and manage the “payment” related columns of the Payments table and are completely unaware of the remaining columns and/or tables. Same goes for Orders microservice.

We achieve secure by design, scalability, domain knowledge isolation and above all compliancy.

I am personally not against the design of microservices, where a dedicated data tier is isolated per service. If you have a single-tenant (or site = e-commerce) type application, you should go this route. My point of view is only subject to SaaS based multi tenancy architecture and of cause – my view.

.