I had my own regretful experience with microservices. I don’t think the architecture itself is a bad concept but I think it wasn’t explained well enough during those early evangelisation stages. The big problem is that in many enterprises SOA patterns were still lingering in the back of peoples minds and most people just saw this as SOA with REST and JSON instead of SOAP. This became an issue when people started scoping the boundaries of their datasets. The big problem was falling back into the thinking of scoping your service around a dataset instead of scoping it around an end user service. The problem is developers perspectives around what an end user facing service is often skewed to how the technology is presently implemented and where that data is stored. They lose track of what the end user business service is. It also didn’t help that examples like the Saga Pattern began to emerge as a way to orchestrate a service that crossed boundaries. To me this is probably closer to an anti-pattern or pattern that she be used rarely. In my last project I ended up with an architecture that relied on it far more than I anticipated and in the end I realised I’d scoped the boundaries for my services wrong. We had to many moving parts. We would typically have to make changes and redeploy at least two and sometimes three repos to change one piece of end to end business logic. It meant our services were too micro and this was the problem. A lot of developers got into the idea that the code base for each service should be small above all else. If it got too big you needed to split out into another services because it was becoming a monolith. But I think that was one of the big common mistakes, thinking that microservices = small simple codes bases. I think a better way to think about microservices would be to think of them a mini-monoliths that should represent one piece of end user functionality. If that mini-monolith needs to reach into four different data stores to do that, then that’s okay. It’s messy for sure and not ideal, but still better than building four services and at least one more to orchestrate them.