9 Comments
Aug 19·edited Aug 19Liked by Raul Junco

Great approach Raul.

Reminds me a bit of a Strangler-Fig-like approach only with events involved for a gradual migration. One risk is that the adapter becomes a permanent component. For this, I'd suggest keeping a hard deadline at some point when it will be decommissioned.

Also, thanks for the mention brother!

Expand full comment
author

That's a great point, Saurabh; the risk of a "temporary fix" is a reality.

A hard deadline with a follow-up is a must!

Expand full comment

That's a great article, Raul! And thank you for the mention!

Expand full comment
author

Thanks, Petar!

Keep them coming.

Expand full comment
Aug 15Liked by Raul Junco

I like this. Typically I’ve made the message backwards compatible or, for major changes, updated the consumers to accept both formats before updating the producers.

This is a simple way to decouple all of it.

Now just need to make sure the consumers get updated and we don’t get stuck with the adapter forever.

Expand full comment
author

Exactly, Mike.

Backward compatibility is my favorite approach. As you mentioned, I like this approach because I don't need to deal with the producer anymore, so consumers can now change at their own pace.

Thanks!

Expand full comment
Aug 15Liked by Raul Junco

I like this. Typically I’ve made the message backwards compatible or, for major changes, updated the consumers to accept both formats before updating the producers.

This is a simple way to decouple all of it.

Now just need to make sure the consumers get updated and we don’t get stuck with the adapter forever.

Expand full comment

A solid breakdown my friend! Keep these bangers coming!

Expand full comment
author

Thanks, Daniel!!!

Expand full comment