A platform group proposes consumer-driven contract testing across 200 services to stop breaking changes reaching production. What do they gain, what do they pay, and when does the bill arrive?

What is gained

• A provider learns at build time that it has broken a consumer, rather than in a staging environment that does not have the real consumer, or in production. That is the whole value and it is substantial: for an estate with independent deploys, this is the only mechanism that catches an incompatible change before it ships.
• The interaction becomes an artefact. A contract records what a consumer actually relies on - which is reliably a small subset of what the provider publishes, and a far better description of the real coupling than the specification is.
• Integration environments get cheaper. If contracts hold, you stop needing an environment where all 200 services run together to find out whether they work together.

What is paid

• A contract per consumer-provider pair, not per service. The number of relationships is what grows, and in a mesh of 200 services the count is in the hundreds. Each one is a test suite someone owns, and ownership is the part that decays.
• A broker and a verification step in two pipelines. The provider's build must fetch consumers' contracts and verify against them, which couples the provider's build to an external service - so broker downtime blocks deploys, and that needs a documented fallback.
• Discipline about what a contract asserts. Contracts that pin exact payloads rather than the fields a consumer reads will fail on every harmless change, and the response is always the same: people start ignoring or deleting them. Tolerant assertions are a skill the estate has to learn.
• A flow for intentional breaks. When a provider genuinely needs to change, the contract is in the way by design, and there has to be a path - a negotiated deprecation window - or teams route around the tool.

When the bill arrives

At about the fiftieth contract, when no single person understands the graph any more and a red provider build is caused by a consumer nobody on the provider team has heard of. The cost at that point is not compute - it is a blocked deploy whose diagnosis requires two teams and a meeting.

The second arrival is the abandoned contract: a consumer team stops maintaining theirs, it pins behaviour nobody depends on any more, and the provider cannot tell whether it is safe to ignore. An unmaintained contract is worse than no contract, because it blocks correct changes with an authority it no longer deserves.

Where to start instead

Not at 200 services. Start with the five or ten pairs where a break would be expensive - the payment path, the authentication path, anything crossing an organisational boundary - and let the pattern spread by demand. Pair it with two cheaper controls that cover a lot of the same ground: schema compatibility checks on every event and endpoint, which need no per-consumer coordination, and a published deprecation policy with a timetable, which handles intentional change rather than accidental.

The decision rule

Contract testing earns its place where consumers are internal, numerous and independently deployed, and where you cannot ask them all to test against you. It is the wrong tool where consumers are external (you do not control their build, so you need versioning and deprecation windows instead), where there are only two or three consumers (talk to them), or where the provider and consumer deploy together anyway (an integration test is simpler and tells you more).

When this is the wrong answer

If the estate's breakages are mostly behavioural rather than structural - a field that still exists but now means something different, a timeout that changed, an ordering guarantee quietly dropped - contracts will pass and production will break. Contract tests check shape, and shape is the easier half of compatibility. That case needs semantic versioning discipline, better release notes and canary deploys with real traffic, and buying a contract broker will not touch it.