One Renamed Field, Three Broken Services
Edited transcript from the published film
https://www.youtube.com/watch?v=eV_qWXB1wY8

One field, three workflows
We changed one field name. The service still runs, but three other workflows may now be reading something that no longer exists.

Our fixture has an order API and three consumers: fulfillment, customer notifications, and reporting. The change replaces one response field. The producer’s own tests are green because they were updated alongside the producer. The consumers haven’t changed.

Freeze the prediction
Before running the failures, we freeze the dependency map and ask which consumers should be affected. This is the prediction. We preserve it before revealing the execution results so hindsight can’t redraw the map.

Follow the business outcome
Now each consumer runs against the new API contract. We inspect the requested field, the received payload, and the business outcome. A service can stay healthy while skipping a shipment or generating an incomplete report. The evidence needs to follow the data beyond the HTTP success code.

Test the migration contract
The correction may preserve compatibility, coordinate a consumer migration, or reject the incompatible release. We choose the fixture’s documented migration strategy and test it. Old and new consumers both receive attention during the transition. A permanent compatibility shim isn’t automatically the right answer. An explicit migration contract is.

Keep the misses
At Zof, we compare predicted impact with observed impact, and we keep the misses. The useful map is the one that helps us decide what to verify before a small change becomes a large surprise. A one-line diff can cross several business boundaries. Show those boundaries before calling the change small.
