One db per microservice, on the same storage engine?

Question

It is considered the best approach that a microservice db is private to it and shared nothing approach is the best.

I recently came across a cloud based system which used postgres, mongodb & elasticsearch. The per service DB is followed, to the extent that each service was running its own cluster of storage engine which hosts only one database.

For instance service A and service B use elastic search (ES) with 3 indices each. they have their own ES cluster on which 3 indices are hosted. Same is the case with other services which use mongodb or postgres where 1-2 collections are hosted on a single mongo cluster or 7-8 tables are managed by one postgres cluster

I'm confused with they way they have followed the design. to my understanding, a separate database does not mean a separate database engine instance. any modern database engine can host multiple databases very easily. a service owns database but not DB engine instance. that not only causes maintenance nightmare but also severe under-utilization of each database engine. Am I correct in my understanding or I have incorrect understanding?

Answer 1

It always depends on what you want to achieve.

For example, if for some reason, you would need to restart a db to reconfigure / deploy a new version of the service, you would influence other teams' services. If you don't want that, you might want a whole different cluster for yourself.

If you want to scale one service's DB completely differently from the other services, you also might want to own your DB cluster.

If you're not interested in any of that, you're right, it would be probably simpler to share a DB cluster. Again, this only works if the sharing doesn't conflict with something else you want.

Answer 2

A microservice architecture intends to ensure scalable, loosely coupled services that are independently deployable. The database per service pattern contributes to this objective by making the data private to a service and avoiding therewith hidden coupling due to interdependencies in the database schemas.

You can group private databases tactically on a same storage engine, as long as the technology used keeps each database independent. This ensures that you could move a base to a separate engine if needed, for example is one of the microservice requires a different version of the engine, or for scalability purpose.

However if you use any mechanism related to distributed databases, such as database shards or mongoDB clusters without keeping the databases separate, the privacy of the data per service is no longer guaranteed: technically, it's the same database that is distributed (shards) or replicated (clusters). You might sooner or later suffer from the kind of hidden dependency that the database per service pattern aimed to avoid (e.g. one service accidentally accesses directly data of another service or database schemes share some common elements).

Answer 3

I think to start with cases where in you don't need strict data isolation, you can adopt a strategy to host service tables in the same Database to start with and later take a call as your system grows.