1 min lesson
Versioning and backward compatibility
Make the call in this situation: "You need to change the response shape of the webhook service that a dozen product teams depend on. How do you ship it without breaking anyone?" Explain what supports it.
Step 1 of 2
Versioning and backward compatibilityyou cannot break product teams
Shared infra changes constantly while its callers can't all redeploy in lockstep. The discipline is additive change: add fields and endpoints, never repurpose or remove them under a live contract. When a breaking change is unavoidable, run both versions and migrate callers off the old one before you retire it.
- Make changes additive by default - new optional fields, new endpoints - so old callers keep working untouched.
- Run contract tests in CI on both sides so a breaking change to the auth or webhook service fails the build, not production.
- For unavoidable breaks, version explicitly, dual-run, migrate callers, then deprecate on a published timeline.
- Treat the contract as the artifact you review most carefully, because it has the widest blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition..