Messaging and events

The next step for the Helping Hands application is to define the interactions between the identified microservices. Microservices can either interact by directly sending the messages to other service endpoints synchronously or they can subscribe to the events generated by other microservices and receive the messages asynchronously. Asynchronous messages rely on the underlying message broker and its durability. Message brokers not only help to scale the application by holding the messages yet to be processed in the queue, but also support durable deliveries. Even if a service fails, it can be restored and allowed to start processing pending messages from the point where it left off. Combining both synchronous and asynchronous message patterns for the Helping Hands application gives us a flexible and performant architecture to accomplish a given task, as shown in the following diagram:

All the services of the Helping Hands application must publish change log events related to the business entities on a message queue that can be read by any service that subscribes to it. The published events must be retained by the message queue for a configured amount of time, beyond which the events may be discarded. For example, all the core services—Service Consumer, Service Provider, Service, and Order—publish events on their designated message queues at the allocated topic.

The Lookup Service must subscribe to all the events published by the Consumer, Provider, Service, and Order services to maintain a local denormalized database to support search queries. It must add geolocation details by querying the external service and caching the results locally. Any changes done to the consumers, providers, services, and orders databases must be communicated to the Lookup Service via events, asynchronously. The Lookup Service may also publish events to its designated message queue for other services to consume. These events are often useful to analyze the number of search queries received, trending services, and so on.

Services such as Alerting are best suited for such asynchronous messages. The Alerting Service should not only rely on the message broker for various delivery semantics, such as at-least or exactly-once delivery but must also read batches of alerts, combine alerts for the same user and send them as a single consolidated alert.

Services such as Order Service may also rely on direct messages to retrieve details of the consumer, provider, and the service before registering an order for the user. Once the order is registered, a change log event must be published by the Order Service for the Lookup Service to make the order available to be searched.