Yes. If you have several consumers of the catalog service, those consumers are bound to a specific version it. You may update the catalog service API as much as

Yes. If you have several consumers of the catalog service, those consumers are bound to a specific version it. You may update the catalog service API as much as you wish, but that will simply open /v2, v3, .../ endpoints - existing services shouldn't be affected. Just like with regular REST APIs. Deprecation of older API versions will be as disrupting as expected, of course. If existing consumer of catalog service needs to make use of the new version features, you update it on its own... Version hell? You can imagine the horrors. But technical debt on an architectural level is something you need to consider any architecture you choose to create your application in. Point of micro services is have your components loosely coupled and independent from one another. If catalog fails, it shouldn't bring down the whole application with it. In our simple example, catalog failure means whole app becoming inert, but in bigger applications you _may_ find benefits of this. Also worth mentioning - load can vary between components. The cart will see less use than the search service, while the catalog will be most loaded. You can make deployment decisions to optimally allocate resources for your application.