Great question—this is a really common friction point when applying Pact's consumer-driven contract (CDC) model to event-driven architectures, especially for breaking changes like removing event fields. Let's break this down:

Why the default Pact flow clashes with your use case #

Pact’s standard CDC workflow assumes consumers define the contract first, providers validate against it, then providers deploy followed by consumers. This works perfectly for backward-compatible changes (like adding optional fields), but it’s exactly backwards for breaking changes (like removing a field) in event-driven systems.

In your example, if you follow Pact’s default steps:

• Deploy the logistics service (provider) without the field first
• Then deploy the order service (consumer) that doesn’t rely on it

...the order service will crash in the gap between provider and consumer deployment, since it’s still expecting the field. That’s exactly the problem you’re hitting.

How to adjust the workflow for breaking event changes #

The key is to prioritize backward compatibility in the consumer first, then align the Pact contract with that state before updating the provider. Here’s a step-by-step fix for your field removal scenario:

1. Update the consumer to handle missing fields first
   Modify the order service to stop relying on the soon-to-be-deleted field, and deploy this version. This makes it compatible with both the old (field present) and new (field absent) versions of the event.

2. Generate a new Pact contract from the consumer
   Update the consumer’s Pact tests to remove expectations for the deprecated field, then publish this new contract to your Pact Broker.

3. Validate and deploy the provider
   Have the logistics service validate against the new contract (confirming it no longer sends the field), then deploy the updated provider.

This way, there’s never a point where the consumer receives an event it can’t handle, eliminating downtime.

Additional tips for event-driven Pact testing #

• Use Pact Broker tags to manage contract versions
  Tag contracts with environment-specific labels (e.g., prod, staging) to keep track of which contract version corresponds to what’s running in production. Once your consumer’s compatible version is live, you can update the prod tag to point to the new contract, signaling the provider is safe to deploy.
• Test for backward compatibility explicitly
  In your consumer’s Pact tests, add cases that verify it can handle events missing the deprecated field. This ensures your compatibility layer actually works before you commit to removing the field from the provider.
• Lean into schema evolution principles
  Even without Kafka/Avro, the core idea applies: breaking changes (like field removal) require consumers to adapt first. Pact doesn’t prevent this—you just need to flip the order of operations for these specific scenarios.

You didn’t miss any key points here—Pact’s default flow is optimized for consumers requesting new features, not providers removing existing ones. Adjusting the workflow for breaking changes is the right approach to keep your event-driven system stable.

内容的提问来源于stack exchange，提问作者Rafaesp