Microservices messaging and coupling

Question

So I am designing some microservices that communicate via messaging and event queues.

However, if I update a message class, for example remove a field, this will break several participating microservices and require a redeployment. I can see microservices can be deployed independently, but not if there is a central change like this.

So is there a way I can update a message class and not fall into this trip of having tight coupling? I am worried I may be missing a technique.

Answer 1

Sure. Easy route: don't make breaking changes to your messages - e.g. adding an optional field to a message is backwards-compatible so you can do that without needing to redeploy everything.

Sometimes you can't do that, so you have to take a longer path:

1. Create a new "v2" message type.
2. Update the consumers to simultaneously understand both the "v1" and "v2" message.
3. Update the producer(s) to emit the "v2" message instead of the "v1" messages.
4. (Optional but tidy) Remove the code to handle the "v1" messages.

Answer 2

I am worried I may be missing a technique.

Useful Literature:

• Versioning in an Event Sourced System. Events are a kind of message, so a lot of Greg Young's guidance applied generally. (Caveat Emptor: the book has been 90% complete for 6+ years now.)

• Versioning XML Vocabularies - these problems have been around for a while

• Why was optional removed from protocol buffers?

  • Eric Anderson
  • Kenton Varda

Answer 3

A prerequisite to designing microservice communication is identifying the type of relationship between them:

• Consumer/supplier
• Shared Kernel
• Conformist
• etc.

DDD's Context Mapping technique helps you do that.

Streamlining your dependencies will avoid unneeded communication and coupling, but some coupling is unavoidable, so yes, you will have problematic changes. Looking at the type of relationship between the 2 microservices will help you determine if you want to go through the trouble of making the changes non-breaking and maintain several versions in parallel, or if it's a waste of time.

Team dynamics also play a big role in this as if 2 microservices are developed by different dev teams with different agendas and deployment paces, it will be harder to keep them in sync. In contrast, 2 microservices maintained by the same people can perfectly be redeployed at the same time if it happens reasonably rarely.