With deployments of code, things get a bit trickier because changing APIs on either the input or output sides or the database schema can wreak havoc on a cluster with interspersed versions of code. To get around this problem, there is a modified blue-green deployment pattern called blue-turquoise-green deployment where the code is attempted to be kept compatible with all running versions until the new code is deployed, after which the service is again updated by removing the compat code.

The process here is pretty simple:

1. The service that uses API version x is replaced with a new version of the service that supports both API version x and API version (x+1) in a rolling fashion. This provides zero downtime from the user's perspective, but creates a new service that has the newer API support.
2. After everything is updated, the service that has the old API version x is removed from the codebase.
3. Another rolling restart is done on the service to remove traces of the deprecated API so only API version (x+1) support is left.

This approach is extremely valuable when the services you are using need to be persistently available, and in many cases you could easily replace the API version with the messaging queue format, if your cluster is based on queues. The transitions are smooth, but there is overhead in needing to twice modify the service compared to a single time with a hard-swap, but it is a decent trade-off. This approach is also extremely valuable when the services in use deal with a database that might need a migration, so you should probably use this approach when others are not good enough.