Blog

Get Our Latest Thoughts & Opinions

Broadcast pattern in Event-Driven Architecture

  • colm_barry

With an ever-increasing number of systems needed for companies to meet business needs and the complexity of data interchange between these systems, the Event-Driven Architecture (EDA) gains popularity by offering reliable message exchange and loose coupling between these systems. 

What is EDA?

The EDA is a software design style based on the events exchange between microservices. The basic design consists of an event publisher which creates a stream of events in real (near-real) time, and event consumers who listen to publishers and consume events. The event represents a change in state for a particular business moment (like a support case is created by the consumer in the e-commerce portal or a notification that the case was resolved). 

The event publisher and event consumers are decoupled, which allows them to be changed and deployed independently. One published event message can be received by many consumers. These downstream systems can filter the received messages and to process them depending on their business logic. In this case, the Broadcast Pattern can be implemented to EDA.

Broadcast Pattern overview

The broadcast pattern is a core element of event-driven architecture, and it allows the published event message to be consumed by multiple downstream systems in parallel in real-time, near real-time, or on an ongoing basis. Fundamentally, it is a one-way synchronization from one system to many. By implementing this pattern, the data consistency will be achieved in all interacting systems. The event publisher acts as a single source of truth, and the event consumers do not need to poll its data.

The broadcasting pattern can be implemented in a publisher-subscriber model by using Topics, where all active subscribers receive messages. One thing to remember is that if the subscriber is not active, a message will not be delivered to it. 

If message persistence to all downstream services is necessary, an extra logic should be implemented which, for example, orchestrates the message delivery via queues to each system (point-to-point messaging). In this case, the implementation logic makes downstream services coupled to it, and every time an additional service needs to be added to this model, the code of the implementation logic has to be updated as well.

Example broadcast pattern in EDA


One of the examples where a broadcast pattern can be applied: when a sales team creates a new account, they want to share that data with other departments (finance, marketing) and to give that account access to a corporate web-portal.

The above example implements a broadcast pattern for accounts one-way synchronization. The source system sends only a notification when a new account is created (Salesforce publishes the platform event to one of its topics). The Mulesoft Process API is subscribed to that topic, and when it receives the event message, it will pull the needed data from the source system. In this way, the Process API is responsible for gathering and handling the account data. This is useful, for example, if the data needs to be enriched from other sources as well before synchronisation happens.

When the Mule process API has all account data needed, it acts as an event publisher and places events to a message broker Topic. The downstream systems are subscribed to this topic, and when a new message is placed in a topic, they consume this event message, and later can also filter it based on their business requirements.

If a new system needs to be updated with account data as well, it can easily subscribe to the same topic and start receiving event messages from the source system with no extra point-to-point integration needed. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Today's post is from one of our Mulesoft Architects, Yurii Kostenko.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

As always, thanks for reading, if you enjoyed this post please feel free to share it and tag us @Pexlify.

Pexlify is a leading digital transformation partner with Salesforce.com.

Want to know more about our Salesforce SolutionsContact us today to set up a hassle-free consultation.

Get In Touch

Discover how Pexlify can create digital experiences that transforms and optimises your business with Salesforce.

Get Started