Broadcast Pattern

The Broadcast pattern refers to the movement of data from a single source system to many destination systems in a pattern that is ongoing and in a real-time (or near real-time) basis.

Whenever your data requirements dictate the need to keep our data synchronized and up-to-date between multiple systems over time, then we need to deploy either a broadcast, bi-directional, or correlation pattern. The broadcast pattern, like the migration pattern, is uni-directional by design and will only move data in a single direction from source to the destination system. Additionally, the broadcast pattern is transactional in nature, unlike the migration pattern.

As an analogy, we can envision the broadcast pattern as a selective process that only captures those items which have field values that have changed since the last time the broadcast ran. Thus, it does not execute the logic of our message processors for all items in scope; rather, it is more selective and will only execute processor logic for items that have recently been updated.

Another major difference from the data migration pattern concerns how the implementation of the pattern is designed. On one hand, The Data Migration pattern will be deployed and refined to manage large volumes of data and process many records in parallel paths and manages a graceful failure scenario. As an alternative, the Broadcast patterns, as a result of their synchronization role, will always be optimal for processing records quickly and reliably to avoid loss of critical data during their transmission.

Value of Broadcast Pattern

This pattern is extremely valuable when application X requires information (in near real time) that has its origins within application Y. For example, your customer requires a real-time reporting dashboard that would, in essence, be the destination point for multiple broadcasting applications that receive real-time updates on key metric aggregates form across the organization.

Here are some additional examples of Broadcast pattern implementations:

• Initiate order fulfilment originating from your CRM, eCommerce tool, or internal application where the fulfilment processing is centralized regardless of which channel it originated from.

• Send a notification of the temperature of critical machinery to a monitoring system every 10 seconds.

• In a patient monitoring system, when a patient is checked into an emergency room it will broadcast any synchronize with their doctor’s patient management system.

There are countless examples of when you want to transfer data from an originating system and broadcast it to another.

Usefulness of Broadcast Pattern

The broadcast pattern’s “need” can easily be identified by the examining the following criteria. When the response is affirmative then the pattern has been justified.

• Does system X need to know as soon as the event happens?

• Does data need to flow from X to Y automatically, without human involvement?

• When system X doesn’t need to know what happens with the object in system Y