The pitfalls of keeping a single shared database

The number one mistake that teams make when deciding to go with microservices is trying to share a single database and scheme with multiple microservices. So, why is this such a bad idea even though it certainly seems easier? Well, let's start with the definition of microservices.

The definition of a microservice states that each microservice should have its own database or data store for which it is responsible for maintaining the state of its data. Therefore, it makes sense that we adhere to this principle of a single database when creating our microservices. It is also reasonable to conclude that when we break up a monolithic application into microservices, we must break apart the large monolithic legacy database into smaller, separate data stores of one per microservice. This breaking up of mature legacy databases is no easy task and should not be taken lightly. An activity such as breaking up a mature database into smaller...