Before deploying, how do you know whether removing a response field will break any consumer?

What is being tested

Whether you know the mechanism that gives integration confidence without reintroducing coordinated deployment.

The reasoning

Each consumer publishes a contract describing only the subset of the response it actually uses — specific fields, shapes and status codes. The provider's build verifies its implementation against every published contract. Removing a field that some consumer depends on fails the provider's build, before anything is deployed and without either side running the other.

The critical detail is only what it uses. A contract asserting the entire response shape defeats the purpose: the provider could then never add, remove or reorder anything, which is worse than no contract at all.

Why the alternatives fall short

End-to-end tests require every service deployed together in a shared environment. They are slow, flaky, expensive, and they reintroduce exactly the coordinated release that independent services were purchased to eliminate. They also tell you the combination currently in that environment works, which is not the combination that will be in production.

Asking in a chat channel relies on everyone knowing what their service depends on and seeing the message. Both assumptions fail, and they fail silently. This is the state most organisations are actually in.

Versioning indefinitely avoids breaking anyone and never removes anything, so the provider accumulates surfaces forever. It is a legitimate strategy for external APIs where consumers cannot be upgraded; it is over-engineering for internal ones where they can.

What makes it work in practice

• Verification blocks the provider's build. A contract check that runs nightly and posts to a dashboard will be ignored within a month.
• A broker holding contracts and deployment state, so the pipeline can answer the operational question: can I deploy this version given what is currently in production?
• Contracts generated from real consumer tests, not hand-written, or they document intentions rather than usage.
• Stale contracts removed when a consumer retires, or the provider is frozen by a service that no longer exists.

The organisational point

Contract testing converts a social problem into a build failure. Without it, "who depends on this field?" is answered by asking around and the answer is incomplete. This is why the practice tends to become necessary at the point where the number of teams makes informal communication unreliable — usually far earlier than people expect, and it is exactly the coordination cost that autonomous-team models are trying to avoid.

The gap worth naming

Most organisations apply contract testing to synchronous APIs and leave event schemas ungoverned, even though published events have the same problem with more consumers and less visibility. A schema registry with compatibility checks enforced in CI is the equivalent mechanism there.