Here are 3 ways to do it successfully.

My first advice is to keep backward compatibility as much as possible, but this is not always possible. So, what should you do?

It requires that the microservice exposes the interface, and all consumers of that interface are changed at the same time.

Of course, lockstep deployment is against “independent deployability.” We need to give our consumers time to change to the new interface.

That leads us to the next two options.

In simple terms, run old and new versions of the microservice side by side.

Older consumers point to the older version, while newer consumers see the new version.

This approach is handy when the cost of changing older consumers is too high or out of control.

My biggest problem with this is the cost of maintenance.

If you have a bug, you must fix and deploy two different sets of services; more infrastructure = more cost.

Have your microservice expose the new interface and also mimic the old interface. You expose both the old and new versions of the endpoint.

To do this, we internally transformed all requests from the V1 endpoint to a V2 request.

This lets us get the new implementation out quickly while giving consumers time to move over.

Once all the consumers no longer use the old endpoint, you can remove it and any associated code.

You must be careful here; you don't want to support 3 different endpoint versions.

My rule of thumb.

I am somewhat OK with a lockstep release if the same team manages the microservice and all consumers. But don’t abuse it, or you will end up with a distributed monolith.

Coexisting different versions works but can be problematic. I have used it when I like to run the microservice versions side by side (Canary Release).

My favorite is an emulation of old endpoints. The challenges are much easier to deal with.

The reality is that when you need to give consumers time to upgrade.

How do you handle your breaking changes?