All Collections
Tutorials
Event-Oriented Architecture
Event-Oriented Architecture

Know what it is and how it works.

Micaella Mazoni avatar
Written by Micaella Mazoni
Updated over a week ago

IMPORTANT: This documentation has been discontinued. Read the updated Event-driven Architecture documentation on our new documentation portal.

One of the most powerful and flexible approaches for the integrations construction is the use of an Event-Oriented Architecture. Know a little bit more about its characteristics and advantages and see how easy it is to implement it through Digibee Integration Platform.

These are some concepts that you need to know:

  • Event: message that notifies other components about a change of state, an occurred action or fact so that the components can react to it

  • Publisher: process that generates the event

  • Subscribers: processes that consume the event

  • Publisher/Subscriber: or just Pub/sub, is the message pattern

To have a better picture of how it works, image yourself in a buying process. The moment you pay and confirm your purchase, a “Make Purchase" process publishes a "Purchase Made" event.

Other processes can also react to the event and make different processing, such as "Consolidate Purchases in the Customer History and Provide Inventory Replacement of purchased products”. In this case, the event published by the Publisher (Make Purchase) is the trigger for the execution of the Subscriber (Consolidate Purchases in the Customer History and Provide Inventory Replacement of purchased products).

These are some of the advantages provided by the adoption of an event-oriented architecture:

  • Decoupled Publisher and Subscribers: from the publication of a single event, any number of processes can respond to it without any changes to the Publisher having to be made - different to what happens with end-to-end integrations;

  • Easy model expansion to support new functionalities: new Subscriber processes can be further developed without any changes to the Publisher process having to be made;

  • Asynchronous execution: the Publisher generates an event without having to know the result of the Subscribers execution, guaranteeing execution independency between the processes;

  • Vertical and horizontal scalability: thanks to the decoupling delivered this model, each process can be separately dimensioned according to its processing characteristics. Besides, adding new Subscribers doesn't cause any impact to the Publisher.

Implementing this model through the Platform is very easy and requires you to follow these 2 steps:

1. Build the Publisher

Create a pipeline that publishes an Event through an Event component. Click here to know how to use it.

2. Build the Subscribers

Create the pipelines that use the Event Trigger set to respond to the event generated by the Publisher. Click here to learn how to set the trigger.

Did this answer your question?