Why are consumer-driven contracts more useful than provider-published schemas, and what does the direction change?
Show the full answer Hide the answer
What the direction changes
A provider-published schema says what the provider offers. A consumer-driven contract says what consumers actually use. Those differ substantially, and the difference is the entire value.
A provider that knows only its published schema must treat every field as load-bearing, because any of them might be used. A provider that knows the union of consumer contracts can change everything else freely.
This converts "we cannot change this because we do not know who depends on it" — the dominant reason interfaces ossify — into a specific, bounded list.
What it enables
1. Safe evolution. Fields no consumer uses can be removed. Fields one consumer uses can be discussed with that team specifically.
2. Failure at the right moment. The provider's build fails before merge, with the affected consumer named — rather than the consumer's overnight batch failing at 2 a.m. days later.
3. Unambiguous ownership. The failing build belongs to the team making the change.
4. Deprecation as a conversation with named teams, on a known timeline, rather than an unbounded broadcast.
What the provider still owes
A published schema remains necessary — it is how a new consumer knows what is available, and contracts only describe existing consumers. The two are complementary: the schema is the offer, the contracts are the actual commitments.
The organisational condition that decides adoption
Consumers do the work and providers get the benefit, which does not happen spontaneously. It requires leadership treating it as the standard, and providers not overriding red contract checks — since one bypass teaches everyone that it is optional.
The discipline that determines whether it survives
Contracts test the interface, not behaviour. A contract asserting that a field is present and is a string is durable. One asserting that a calculated total equals a specific value is a business-logic test in the wrong place — it breaks on legitimate changes, becomes noise, and produces the conclusion that contract testing does not work.