Observer model

The observer model uses a message broker (https://en.wikipedia.org/wiki/Message_broker) at its core to send messages among microservices. A message broker provides content and topic-based routing using the publish-subscribe pattern (https://en.wikipedia.org/wiki/Publish-subscribe_pattern), which makes the sender and receiver independent of each other. All observing microservices subscribe to one or more topics through which they can receive the messages and also connect to topics on which they can publish the messages for other observers. All interactions done via message brokers are asynchronous in nature and do not block the sender. This helps in scaling both the publishers and subscribers independently. A microservices architecture that is built on only asynchronous and non-blocking interactions using message broker scales very well.

Message brokers are also used to manage workloads in scenarios where the rate of published messages is higher than the rate at which the subscriber is able to process the messages. Message brokers also provide reliable storage, multiple delivery semantics (at least once, exactly once, and so on), and also transaction management that is useful for data management across microservices.  Binary message formats such as Thrift, ProtoBuf, and Avro are preferred over text formats for message brokers.

In the observer model, all the requests generated by users, applications, or microservices are published on a topic to which one or more microservices can subscribe and receive the message for processing, as shown in the preceding diagram. The generated results can also be written back to a topic that can be later picked by another microservice, which may either report the response back to the application or persist it within a data store. If a subscriber fails, the message broker can replay the message. Similarly, if all subscribers are busy, the message broker can accumulate the messages until they are processed by the subscribers.