The typical approach to catching this that I have seen is to deploy the new version of Service X to only a small percentage of all machines for a certain amount

The typical approach to catching this that I have seen is to deploy the new version of Service X to only a small percentage of all machines for a certain amount of time. E.g. 1% of machines get v1.1 while all others stay on v1.0. You then monitor error rates in v1.1 (and its dependencies) and stop if there are elevated levels, or crank the release up slowly if the error levels aren't elevated. Obviously some automation in your release management and monitoring tools helps a lot with this. Of course this does not "solve" the problem of incompatibilities themselves - for that the simple solution that I've seen used is just bog standard versioning of APIs (/v1/... /v2/... /v2019-03-04/... etc) and some procedures for managing the supported versions, e.g. not doing breaking changes in an existing version, only supporting a set number of versions (i.e. previous, current, and next), and having proper sunset-periods for older versions before they are turned off so clients have time to update. Slows velocity to do all this management but that is life anyway in a complex system