Consumer-Driven Contract

The problem it solves is specific and expensive: in an estate of independently deployed services, a provider cannot know whether a change breaks a consumer, and the usual answer — a shared integration environment running everything — is slow, flaky and gets worse with every service added.

The mechanism inverts the direction of the check. Each consumer records exactly what it needs from the provider: this request produces a response containing these fields with these types. Those expectations are published to a broker, and the provider's own pipeline verifies them. A change that breaks a consumer fails the provider's build, before deployment, without either team booking an environment.

The property that makes it scale is that verification is a unit-speed test on each side, so cost grows linearly with services rather than combinatorially.

What it does not do is worth being clear about: it verifies the shape of the interaction, not the correctness of the business behaviour behind it, and it only covers consumers that have written contracts. It replaces most integration testing between services; it does not replace the handful of end-to-end journeys that prove the whole path works.