Generally, there are 2 ways to have microservices communicate with each other . One technique uses REST to have 1 service directly query or act on another service. The other technique has services pass messages over a message bus. There is plenty of information online about what makes a good REST endpoint, but what makes a good message? There are two ways to think about this question. What does a good message look like? What is a good message about?
A good message doesn’t necessarily need much and is definitely a less is more type of situation. A message needs some identifying information. Who sent it? What’s it about? Some verb? A message also needs a payload. If you separate the what from the content you can then encrypt the message itself without impacting the consumers ability to determine if it’s a message worth paying attention to or not.
What goes in a good message? This is a bit more interesting to me and probably a lot more subjective. I believe this is the true difference between using REST or message passing. In REST one service is asking something of another service, but in message passing one service is telling all the others that something happened. In REST, service A would ask service B for some information, but in message passing service B would send a message letting everyone know about the new state of the world which happens to be consumed by service A.
The downside, and hidden upside, to this is that information will be duplicated. When service B sends an event saying a resource was added and service A consumes that event, service A likely needs some place to store that information. This means duplication of information which is unfortunate. Though a positive is that service A isn’t depending on service B running which increases the stability of your system. Another positive is that service A can store the information in a way that suites it’s needs (I would go so far as to say that it is a bad smell if a resource looks exactly the same in 2 different services).
By keeping all messages in the system informative, instead of action requests, it should be faster to create a system with faster response times. Because all services have centralized the information they need to do what they need, they will not send requests to other services, cutting out extra network time.
What makes a good message? Keep the message itself separate from information about the message. Keep it simple. Stick to messages that inform other services of events that occurred. Avoid messages that ask another service to do something.