Microservices Without the Complexity or Architectural Concessions

Hello. Having had a couple of microservice project under the belt now, I would say that yes, it is not the end of the world to be in one database. However, it is my strong belief this should only be temporary and not the norm. It is a valid migration path when transforming a monolithic to microservices for sure. If one is using SQL Server where schemas exist inside a single database, one can separate the microservices' data in schemas.

But as one can learn by reading about the topic, microservices need to be independent. Sharing a database goes against this principle, even more if you make the source of its data dependant on the database server technology. This kills the microservice's buzz by constraining it to one type of database or one subset of all possibilities. If the microservice wants or can benefit from another DB engine, now you are out isolated, with no means to obtain data because only the "buddies" that use the same DB can get into the data flow.

So if your change is required to achieve some important milestone, like performance, or saving data in a way the current DB cannot, will force you into messaging for sharing the source of truth's data. Now you are back to square 1. If needing messaging was then always on the table, it is just best to plan for it from day one.

So in retrospective you can conclude it was best to adhere to the microservice specification from the start. All the rationale applied to bypass it was a mistake, etc.

If someone comes asking me if they should replicate data under the hood like this, I'd definitely tell them to be a mistake.