--- title: "Comment by José Pablo Ramírez Vargas on \"Microservices Without the Complexity or Architectural Concessions\" | Hashnode" description: "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 i" url: "https://hashnode.com/posts/microservices-without-the-complexity-or-architectural-concessions/6373067f5540f6dbf294bf71/comment/6373a127d81a95516cadeeef" --- [Discussion](https://hashnode.com/posts/microservices-without-the-complexity-or-architectural-concessions/6373067f5540f6dbf294bf71) Comment [Microservices Without the Complexity or Architectural Concessions](https://hashnode.com/posts/microservices-without-the-complexity-or-architectural-concessions/6373067f5540f6dbf294bf71) [José Pablo Ramírez Vargas](https://hashnode.com/@webJose) [Nov 15, 2022](https://hashnode.com/posts/microservices-without-the-complexity-or-architectural-concessions/6373067f5540f6dbf294bf71/comment/6373a127d81a95516cadeeef) 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. [Joe Auty](https://hashnode.com/@joeauty) [Nov 15, 2022](https://hashnode.com/posts/microservices-without-the-complexity-or-architectural-concessions/6373067f5540f6dbf294bf71/comment/6373a127d81a95516cadeeef#reply-6373dd22747bca51e27c9fd3) Thanks for your reply! I'd like to learn from this by clarifying a few points you've made, if you don't mind? I definitely agree that sharing a database is not an ideal end result in many/most circumstances, and your point about being tethered to the same DB engine is a good one. Would you say that there are circumstances where the complexity of messaging to share the source of truth's data overshadows the cons of sharing the database? In a purist's world, a microservice would never need data from another service (that cannot be passed down in the initial payload), but it seems like it is pretty common that tech debt is accrued when this no longer becomes the case? This seems to be one of the most common pitfalls of the architecture, would you agree? I'm curious what you feel about the second set of options for sharing copies of data as an alternative to sharing the entire database, or as an alternative to spinning up messaging to get at data that belongs to another service? Thanks again for weighing in! [José Pablo Ramírez Vargas](https://hashnode.com/@webJose) [Nov 18, 2022](https://hashnode.com/posts/microservices-without-the-complexity-or-architectural-concessions/6373067f5540f6dbf294bf71/comment/6373a127d81a95516cadeeef#reply-63770f30abd2877933908d27) [Joe Auty](https://hashnode.com/@joeauty) 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.