Integration failures between 30 services are found in a shared staging environment, days after merge. Propose a change.

Why the current model fails

A shared staging environment is a serialised, high-latency feedback channel. Failures are found late, attribution is ambiguous (whose change broke it?), and the environment's own instability masks real problems. With 30 services it becomes a permanent queue.

End-to-end tests do not fix it: they are slow, flaky, and require every service deployed together — the opposite of independent deployability.

Consumer-driven contract testing

Consumers record what they actually depend on — the requests they make and the response elements they rely on — as part of their own test suite. Those expectations are published to a broker.

The provider's pipeline verifies it satisfies every registered consumer, and fails the build if not. In seconds, before merge, with no shared environment.

Why it is better than a schema check

An OpenAPI spec describes what the API offers. Contracts capture what consumers use.

That difference is directly actionable: a field no consumer reads can be removed; a field one consumer reads cannot. Without it, nobody knows which is which, so nothing is ever removed and APIs only accrete.

The parts that cost effort

Provider states — setup handlers that put the provider into the condition an expectation assumes ("GET /orders/123 returns a shipped order"). Each distinct precondition needs one, and they must stay valid as the data model changes. This is the bulk of the implementation work.

Version and environment tags, so the provider verifies against consumer versions currently deployed, not every version ever recorded. Without this, old contracts block valid changes.

Can-I-deploy checks gating release on whether the versions about to ship are compatible with what is live. This is what makes independent deployment safe.

The real obstacle is organisational

Providers must accept running consumers' expectations in their pipeline — a build failing because of another team's test. That is a genuine cultural change and the usual reason adoption stalls.

Make it acceptable by framing it correctly: the alternative is finding the same failure later, in shared staging, where it blocks everyone.

Rollout

Start with one high-value pair — a provider with several consumers and a history of breakage. Prove it catches something real. Expand outward from there.

Keep a small end-to-end suite for critical user journeys. Contract testing verifies interfaces, not whether the system as a whole does the right thing.