[ecnahc515]

Deployment ordering at large scale is avoided and usually done by not making breaking changes. 4 phase migrations, always. Roll out new API, update existing software to use new API, wait for everything to stop using old API + backfill, remove old API.

[erik_seaberg]

I agree that gradual adoption of new APIs is the way to go, but once you're doing that you no longer need an atomic commit across all projects.

[dehrmann]

You actually never want an atomic commit for that class of changes across projects because HEAD should always be deployable to all services. It's obviously messier at FAANG-scale, but with even 25 devs, not properly staging API-breaking changes leads to a lot of "only deploy commits before xxxx to service foo."