Joe Auty In my short experience in microservices, which is so far 2 projects, I would say I haven't encountered a scenario that is so complex that cannot be transmitted in some form. I am therefore inclined to respond that No, I would not support using the same database or a same-database mechanism to share data between microservices behind the scenes.
For example, what would be considered "complex"? In my mind my limited imagination can get to say, a scenario where some Record-Of-Origin data is used to perform calculations in another microservice, and said calculations are then required by yet another microservice. This is as complex as I can imagine right now. If you have a better more complex scenario, by all means, provide it.
In this most complex scenario, I'd say it is still pretty simple to chain the data in a near-realtime ecosystem powered by message queueing. By simply tagging the messages appropriately, the farthest microservice in the line can simply wait its turn (the appropriately tagged message).
So I guess that, in my short-lived microservices career, I'd be against data sharing behind the scenes at the database layer. Maybe time will prove me wrong, I don't know. This is what I know now. Time will tell.
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.