hi all, I'm afraid my searching skills were not enough and I have to ask here. I'm considering Pact for Messages with the diagram I attached as our example of event-driven architecture. Imagine that we want to introduce a change in the

OrderRequested

message. In Pact, the code of the providers has to be merged first, and the code of the consumer after it. This makes sense to me but I'm struggling to see if it also makes sense for event-driven architecture. If we merged

Basket Service

first, there would be errors (or at least a queue of messages) because

Payment Service

, the consumer, doesn't understand the new changes introduced by the provider. For me, in this case, we would introduce some code to the consumer to be able to handle both the old and new versions of the

OrderRequested

message, and after that, we'd merge the code to

Basket Service

. How would you handle this scenario, please? Was it clear enough? Thanks!

Hi @Rafa ! I dont know if I understand completely your flow but in general with Pact you have to avoid breaking changes! The provide should be merged first, adding a new field for example and no consumers should fail because no one is using that field. When you remove a field instead you will have to approach it on the opposite way around it. You first want to make sure that no one is using that field anymore (thank you Pact) and then you can safely remove the field.

Thanks for answering! I guess my problem is that I really need a breaking change, but I wanted to solve it by adding some code in

Payment service

so that it understands both the old and the new version of the

OrderRequested

message. How would we deal with breaking changes in general?

I would use expand and contract! You first add a new field for example, you start consuming it! Then you remove the old field and thats it

thanks again I need a new version of the event, but I guess I can't merge the consumer first in a way that understands both the new and old versions. Instead, I need to publish both versions from the provider. I was thinking this was not ideal because I would be duplicating Payments. If I publish

OrderRequested

and

OrderRequestedV2

, then it'd be hard to ensure that only one of them is handled if PaymentService is deployed in a "RollingUpdate" mode. Do you see any way of improving this flow?

Its completely normal to deploy the provider first! You could publish both events, and update your consumers one by one to listen only for the new event! When the no one uses the old event you can update the provider to stop publishing the deprecated event!

but what if version 1.12 of

PaymentService

reacts to

OrderRequested

and creates a

PaymentProcessed

event but also version 1.13 of

PaymentService

reacts to

OrderRequestedV2

and also creates a

PaymentProcessed

? I was thinking I wouldn't be able to have multiple containers of

PaymentService

being upgraded 1 by 1 (the RollingUpdate strategy) because of this reason 🤔