Problem
Provider changes API. Consumer breaks in production. Integration tests are slow, flaky, and don't catch contract drift.
architecture-descriptionestablished · medium operational burden
Consumer-Driven Contracts (CDC)
Also known as: cdc-testing, pact, contract-testing
Intent
Ensure provider changes don't break consumers by making consumers define their expectations as executable contracts.
Forces
- •Provider and consumer deploy independently
- •Integration test environments are slow, brittle
- •Need fast feedback on breaking changes
- •Contracts must be versioned and verifiable
Solution
✓ When to Use
- •Microservices with independent deployments
- •Multiple consumers per provider
- •Breaking changes cause production incidents
✗ When Not to Use
- •Monolith or few services with coordinated deploys
- •Public APIs with unknown consumers
- •Team not ready for contract discipline
Pros
- +Fast feedback: minutes in CI, not hours in staging
- +No integration environment needed
- +Explicit contract documentation
- +Prevents breaking changes reaching prod
Cons
- −Contract maintenance overhead
- −False confidence: contract passes but semantic change
- −Provider states: test data setup complexity
- −Broker infrastructure: another moving part
Cost Profile
Infrastructure
Low — broker, CI integration
Operational
Medium — contract lifecycle, broker
Cognitive
Medium — contract thinking, provider states
Failure Modes
Contract drift: consumer doesn't update contract
Provider state mismatch: test passes, prod fails
Broker down: CI blocked
Over-specification: implementation details in contract
Real-World Examples
Alternatives
- integration-tests
- api-versioning
- schema-registry
- e2e-tests
Related Patterns
- api-versioning
- api-gateway
- consumer-driven-contracts
- schema-registry
Competency Domains
distribution communicationdeploymentreliability opseconomics evolution