> You're not allowed to have a share DB with microservice architecture. The law won't prevent you, but indeed it is impractical. As I said before, things like

> You're not allowed to have a share DB with microservice architecture. The law won't prevent you, but indeed it is impractical. As I said before, things like schema upgrades become impossible if you don't have the ear of other teams. When you can't call up another team you also lack trust, so security becomes an issue as well. This is why teams who operate in independent silos must ultimately have their own databases. The practice has nothing to do with performance, though. Microservices has little to do with technology at all. It is about people. > The more I work with microservices, the more I'm convinced that microservice first architecture is garbage. I personally steer clear of organizations so large that they need to silo their teams internally, but I have had a positive experience using services provided by other companies with the only communication between us being API contracts. The concept works well enough. At least so long as the product does what you need of it. If you try to force big business practices into a small organization, you're no doubt in for a bad time. That said, I don't get the impression you are talking about microservices at all, just a bad case of over-engineering.