Member-only story
Why a shared database is considered an anti-pattern in the microservice architecture
Data sovereignty is a rule that states that each microservice owns its domain data and logic. Other microservices that wanted to access or modify that data, will need to pass for the microservice itself for doing it.
I spent some time asking myself the reason for this rule. It seems so easy and time-saving having all your data available to query in a single database.
I came out with this explanation.
How do microservices look when data are fragmented?
Let’s pretend we have three microservices, Orders, Payment and Customers and all are working with the same entity, User. Each of them will only store a fragment of it, the part they will work the most with.
It is very likely that most of the time the payment microservice won’t need to access data that are in the orders microservice if the services boundaries were set correctly.
When data need to be shared between services, this will typically happen using some type of asynchronous message exchange: an example could be with Azure Service Bus or HTTP polling.
Would a shared database make thing simpler?
