In any microservices architecture of a decent size, you're often making changes that have been requested by other services and will request other services to ma

In any microservices architecture of a decent size, you're often making changes that have been requested by other services and will request other services to make changes to accommodate your needs. That's coordination, and it requires overhead. But if you're going the microservices route, you probably already have the overhead and splitting your app into many small services makes the overhead easier to quantify. And very rarely can you implement a feature without touching multiple microservices. Hell, that's why the concept of epics even exists: you have many smaller user stories inside the epic that need to be coordinated to deliver a single feature. Your UX needs the back-end service calls to exist before they can release their UX changes.