Should Each Microservice Have Its Own Database? by Dmitry Belyaev

We all heard a mantra saying “each microservice should have its own database” but is this always true? What about a situation when we split one business domain (bounded context) into several microservices because of some technical reasons. Does this statement hold true in this situation as well?

Working as a consultant helping clients to build distributed, microservices-based systems Dmitry faced this situation quite often. In this talk he will explain what challenges such situations bring and share different ways how these challenges can be addressed.

DMITRY BELYAEV
Dmitry is a Staff Solutions Architect at VMware Tanzu Labs (former Pivotal Labs). As a part of the Application Modernization team inside VMware Tanzu Labs Dmitry supports VMware customers on their application modernization journeys. He helps customer engineers to learn modern principles of software design and development. Dmitry is passionate about Domain Driven Design, distributed microservices-based architecture and XP development practices.

[glebbondarenko]

I won't say that I disagree with the idea. Then we should think about how to deploy 2 services that share a database layer.
Having monorepo with shareable code can give you a false sense that all services already applied a new schema, but it's not true, and it becomes dangerous if you make breaking changes.

So the next statement that I can challenge is `model duplication is always bad` :)

[upgradeplans]

The summarizing point "Database belongs to a business domain (bounded context) not to a microservice" is the one point that I think is not good advice, while I agree with the rest.
The problem is that a bounded context is a logical construct ( @1:45 ), but a database necessarily needs to be physically deployed. This means that a database can never span more than one microservice. Otherwise, multiple database-using-microservices are no longer independently deployable from each other.

It is of course possible to promote the database to be its own microservice. Microservices don't imply anything about the technical protocol used for communication between them, so the database protocol plus the data definition can itself be a perfectly sensible boundary-protocol between the services. If this is handled correctly, then the database becomes independently deployable, and guarantees backwards compatability with all currently deployed clients.
This brings technical chalenges of its own, depending on the technologies used and the structures of teams, but it can indeed also solve some technical chalenges, which I think was the main point of the talk.

[andyvandenberghe]

that is a good point. a database should be bound to its context, the technical interpretation can be divided into several micro services.

[RiccardoPasquini]

The difference between bounded context and microservice pushes me behind several years... Sort of SOA

[minor]

Micros34vic3s is about teams not about deplorable units. It was said by himself who coined the term. Individual operable teams even in budget terms.

[RonaldTetsuoMiura]

They're not multiple microservices, it's a micro-distributed-monolith. And that's ok. Microservice != container.

[tobyzieglerrr]

That was a very good talk, enjoyed it very much and a crucial point was very well presented (use APIs to access the "db owning" service). I have mixed feelings and experience with the monorepo approach. It sounds good, it has some benefits. But still, in reality it mixes concerns (deployment and code sharing) imho. I have seen it being misused to "share" common configurations of services and a lot of other weird stuff. Then the discussion about build times and instant feedback which leads to a lot of effort going into differential build complexity. There is no such thing as a free lunch... or: it depends 🙂

[sergeykichuk]

In first example the job “microservice” it is not microservice it is just a service, first because it is not independent and the second is not a separate from the bounded context! Author forgot that the main idea of microservice is to be independently deployable units!

[shailabsingh]

awesome i feel blessed with this channel and this is a perfect use case of all i needed.

[dmitrybelyaev]

A slightly extended version of this talk is available on Medium

[matheusmarabesi]

to the point scenarios and examples, thanks for that!

I just found out that usually developers push back when monorepo is suggested, any recommendations to improve that?

[berndeckenfels]

Same project suture works for single- and distributed moduliths as well.

[balazsklezli]

Interesting talk, thanks for sharing it!