Microservice Patterns | Design Patterns | Event-Driven Messaging


Microservice and Containerization Patterns > Event Processing Patterns > Event-Driven Messaging
Home > Design Patterns > Event-Driven Messaging

Event-Driven Messaging (Erl, Naserpour)

How can microservices be automatically notified of runtime events triggered by other microservices?

Event-Driven Messaging

Problem

Events that occur within the functional boundary of each microservice may be of relevance to other microservices. But, without resorting to inefficient polling-based interaction, the other microservices have no way of learning about these events.

Solution

A microservice can establish itself as a subscriber of events that occur in another microservice. The subscribed-to microservice, in turn, automatically issues notifications of relevant events to its subscribers.

Application

An event-based messaging framework is implemented, capable of supporting publish-and-subscribe functions and associated complex event processing and tracking.

An event management program is introduced, allowing microservices to set themselves up as subscribers to events associated with a target microservice that assumes the role of publisher. There may be different types of events that each microservice makes available. Other microservices can choose which they would like to be subscribed to.

When such an event occurs, the publisher microservice automatically sends the event details to the event management program, which then broadcasts an event notification to all of its subscribers.

Event-Driven Messaging: Microservice A requests that it be set up as a subscriber to the event it is interested in by interacting with an event manager. Once the event occurs, Microservice B forwards the details to the event manager which, in turn, notifies Microservice A (and all other subscribers) via a one-way, asynchronous data transfer. Note that in this case, Microservice A also receives the event information earlier because the event details can be transmitted as soon as they’re available. 

Microservice A requests that it be set up as a subscriber to the event it is interested in by interacting with an event manager. Once the event occurs, Microservice B forwards the details to the event manager which, in turn, notifies Microservice A (and all other subscribers) via a one-way, asynchronous data transfer. Note that in this case, Microservice A also receives the event information earlier because the event details can be transmitted as soon as they’re available.

This pattern can be applied by implementing the event management program as an isolated microservice, as explained in the complete pattern description.

Module 10: Advanced Microservice Architecture & Containerization.

This pattern is covered in Module 10: Advanced Microservice Architecture & Containerization..

For more information regarding microservice and containerization courses and accreditation,
visit the Microservice Architect Certification program page..