API contract testing

Prevents breaking changes by letting consumers specify the exact contract fragments they depend on, so providers receive automated early feedback before deploying incompatible releases.

Microservices: multiple teams consuming a shared REST or gRPC API with independent release cadences

Microservices architectures, Pact framework, Spring Cloud Contract, distributed systems, API design

consumer defines expected request/response → publishes contract to broker → provider verifies against contract → CI gates deployment

• Pact broker
• provider verification
• consumer test
• mock server
• schema validation
• CI pipeline
• provider states

• Provider-driven contracts (provider defines schema
• consumers adapt — less flexible for consumer needs)
• End-to-end integration tests (full system tests — slower and more brittle)
• Schema-first API design with OpenAPI (validates shape only
• not behavioral expectations)

Treating CDC as a replacement for integration tests: CDC catches contract violations but not network, latency, or state issues; Not versioning contracts in a shared broker: leads to stale contracts and false confidence; Over-specifying contracts: including fields consumers do not actually use creates unnecessary coupling; Running provider verification only on demand instead of in CI: defeats the early-feedback purpose; Confusing CDC with schema validation: CDC covers behavior and interaction patterns, not just data shapes

Schema validation: checks data shape only, not interaction semantics; Integration testing: tests full system, slower and more environment-dependent; Mock services: simulate providers but do not verify real provider compliance

Coming from monolithic development: may assume a single team controls both sides — CDC is specifically designed for independent provider and consumer teams; Coming from SOAP/WSDL era: may expect provider-defined WSDL contracts — CDC inverts this by letting consumers drive the contract

• contract testing
• Pact
• provider verification
• consumer tests
• schema-first design

CDC works best when there are two or more consumers with genuinely different needs from the same provider; for a single consumer, the overhead of a contract broker may exceed the benefit. Performance impact is minimal since contract verification uses lightweight mock matching rather than full integration. Boundary condition: shared mutable state or asynchronous messaging patterns require additional tooling beyond standard HTTP CDC frameworks.

Enables independent deployment of microservices by giving providers automated, fast feedback when a change would break any consumer, reducing cross-team coordination overhead and preventing production incidents from contract drift.

Consumer-driven contracts: like a restaurant letting regulars write their own order tickets — the kitchen knows exactly what each customer expects and will not change a dish without checking.

Contract-driven API governance with Pactflow or schema registries