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.

  • 1
    "So I am designing some microservices" - why are you designing multiple microservices at the same time? One of the big points of microservices is that they should be capable of each one being designed (and deployed) independently. If you are designing them together that could be a sign that you don't need separate microservices.
    – bdsl
    Sep 1, 2023 at 8:26

3 Answers 3


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.
  • Makes sense. I can add fields and deserialize json without any issues as c# supports dynamic objects. But for your idea, basically work backwards and ensure consumers are ready to to support v2 and then update the producer. Aug 31, 2023 at 15:45
  • 1
    The other thing is I could use the "deprecated" attribute for fields no longer supported. Aug 31, 2023 at 21:44

I am worried I may be missing a technique.

Useful Literature:


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.

  • Downvoter on mine and @VoiceOfUnreason's answer care to explain? Sep 1, 2023 at 13:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.