Messaging: How do your messages look like

Question

This question is about message queueing in between a service architecture. There is hardly something to find about this topic.

The situation: Microservice A and microservice B. Microservice A deals about entity "something" and B needs to about. I keep it general to avoid discussions about boundaries.

In our case A sends a message which contains event and related entity id like Event: somethingCreated SomethingID: 1234

B consumes this message and if it needs further information it fetchs this from A with SomethingID.

The second approach would be that the message not only contains the information above but also meta data like Event: somethingCreated SomethingID: 1234 SomeFieldKey: someFieldValue ...

Lean message: Pro: * Less network usage * Always the same structure of messages Cons: * If information from A is needed on demand there must be some mechanism to catch e. g. network failures

Fat message: Pro: * Information is already there Con: * What if the attached information is not enough?

So it has both pros and cons and my intention here is to get an overview Which approach you are using.

Thanks for answers in advance

Answer 1

Simple answer is it depends, We have services that expose all the data with their events and we have services which just shares the reference id and also services which are between these two when it comes to event payload.

Our point is the service which is producing events is mostly in control of what the content of payload will be. We review the use case and monitor the usage of the events and services call and accordingly and make the payload fatter or leaner. We do have an upper limit on our message size but other than that no restriction.

When data flows in between services network latency has not been an issue for us.( I mean not because of increase in size of the payload)

So you need to allow your individual services to take a call. Each service has an SLA to meet in terms of response time and when it gets breached, you review, find out bottlenecks and resolve them.