Sort of, but only for major versions, and it's preferable to bake that sort of thing into the API itself. The API exposed by a microservice should only ever be

Sort of, but only for major versions, and it's preferable to bake that sort of thing into the API itself. The API exposed by a microservice should only ever be updated in backwards compatible ways unless you can verify that you have no callers, which is hard. New functionality should be introduced using backwards compatible constructs like adding fields to JSON or protobuf. Breaking changes go in a new API. This is easily managed conceptually by having the microservice expose version information as part of the API. A FooService might define "v1/DestroyFoo" and "v2/DestroyFoo" with different calling contracts. Perhaps v1 was eventually consistent and returns a completion token that can be used with a separate "v1/CheckFooDeletionStatus", but now with v2 the behavior has been made strongly consistent and there is no "v2/CheckFooDeletionStatus". The v2 of the API can thus be thought of really as a separate API that happens to be exposed by the same microservice, and pre-existing callers can continue to call the (perhaps now inefficient) v1 API.