All of the previous is not to say that one size fits all. When designing a reactive microservice system, you want to choose the best messaging pattern for the purpose. To analyze message needs, it is helpful to categorize the contents as queries, commands, or facts:
Asynchronous messaging provides a simple scalable pattern that you should take advantage of whenever possible. However, synchronous messaging can — and should — be accomplished as efficiently as possible. For example, the sender might wait for a simple acknowledgement from the receiver and continue its work, expecting a reply from the receiver with the answer at some future point.
In a complex microservices system, queries often need to join data in ways not supported by the initial domain model. This is where Command Query Responsibility Segregation (CQRS) comes into play; by separating the read and write models of a system.
CQRS decouples the microservice writing an event from readers that might be performing some action in response to the event. This increases reliability, stability, and availability of the system. The read and write sides can then be scaled independently, taking best advantage of the available resources.
A decoupled design like this (using event sourcing and CQRS) makes for a lot of flexibility, gives us more headroom and knobs to turn, and allows us to better optimize the hardware efficiency, putting the money where it matters most.
From Reactive Microsystems, The Evolution of Microservices at Scale by Jonas Bonér.Next up → Persistence
In less than 15 minutes:
In less than an hour:
Really dig in: