People really underestimate the eventual consistency thing. It's 100% the case your app will behave weirdly while it's processing some sort of change event. The

People really underestimate the eventual consistency thing. It's 100% the case your app will behave weirdly while it's processing some sort of change event. The options for dealing with this are real awkward, because the options for implementing transactions on top of microservices are real awkward. Product will absolutely hate this, and there won't really be anything you can do about it. Also fun fact: this scales in reverse, as in the bigger and better your company gets, the worse this problem becomes, because more services = more brains = more latency. Relatedly, you can't really do joins. Like, let's say you have an organizations service and a people service. You might want to know what people are in which organizations, and paginate results. Welcome to a couple of unpalatable options: - Make some real slow API calls to both services (also implement all the filters and ordering, etc). - Pull all the data you need into this new 3rd service, and justify it by saying you're robust in the face of your dependency services failing, but also be aware you're adding yet another layer of eventual consistency here too. This is the simplest this problem can be. Imagine needing data from 3 or 13 services. Imagine needing to to synchronize UUIDs from one service to 20 others. Imagine needing to also delete a user/organization from the 30 other services that have "cached" it. Etc etc. I used to think microservices were an adaptation to Conway's law, but now I really think it's a response to the old days when we didn't have databases that scaled horizontally. But we do now (Cockroach, Big Query, etc) so we really should just move on.