MCPA MuleSoft Certified Platform Architect Level 1 – Event Driven Architecture

1. What is EDA?

Hi. Welcome to the new section. In this course. In this section, we will focus more on the event driven architecture. We will learn what it is and how it fits in the Mule Soft application networks and works, along with API Led connectivity. Before we go to that part, let us first understand what is an event driven architecture? Driven architecture is an architecture which uses events to trigger and communicate between the systems, okay? Thereby giving high decoupling between the systems. This is very common in the modern applications. In fact, from the last decade itself, many projects or companies are using the EDA. So what is an event? An event is anything like a change in state or an update. Like for example, if you take an ecommerce website or our logistics example, right?

So an item that is being placed in a shopping cart, for example, or shipment notification, that order is shipped. So these kind of things are events, okay? So events can either carry the state, which meaning the item that is purchased, its price and the delivery address, which means the shipping location and all. Okay? The whole thing can comprise as an event or it can be just an Identifier or a notifier that an order has been shipped, that’s it with an order number. Okay? So it can be either an indicator or a whole state of the particular transaction.

So what do we need to implement this event given architecture? Generally, there are three key components that are required to achieve the event driven architecture. They are event producers, event routers and even consumers. If you are already aware of the Pub sub mechanism and all, you can compare this like event producers or the services that publish the messages. Even routers are nothing but the messaging brokers or messaging systems. And the event consumers are the subscribers. Producer publishes an event to the messaging broker, which filters and pushes the events to the consumers. OK? This way the producer services and consumer services are completely decoupled, which allows them to be scaled, updated and deployed independently. Okay?

2. Benefits of an EDA

So what are the benefits of an event driven architecture? Let us see them. First one is scaling and failing independently. By decoupling your services, they are only aware of the event router, okay? Not to each other. So producer won’t be knowing about the consumers and consumer won’t be knowing about the producers. The only common entity here is the event router, which means messaging broker. This means that your services are interoperable. But if one service has a failure, the rest will keep running. Because if a consumer is down, then the publisher or the producer is not at all aware of it. So the producer will keep giving the events to the event router. And it’s the router’s job to make sure that the messages are delivered to the consumers once they are up or eventually.

Okay? The event router is the one which acts in the middle as a mediator. Next one is Develop with Agility. You no longer need to write any custom code to pole, filter and route events, right? Because the event router will automatically does these things for you. Filtering and pushing events to the consumers. The router also removes the need for some heavy coordination between the producer and consumer services. This actually speeds up your development process a lot. Okay, next one is audit with ease and even rotor acts as the centralized location to audit your application and define various policies or rules, okay? Because it’s like a one time setup you do in the messaging broker. Just you have to configure some topics or messages, set some rules like okay, which producer has to publish what events and which consumer is interested to listen on what events, et cetera.

Once the set up is done, it’s a central place. Then the publishers and the consumers are completely mutually exclusive to each other. Magic will happen from the router only, which will go to one particular consumer. Okay? So these policies can restrict who can publish and who can subscribe to a router and control which users and resources have permission to access your data. You can also encrypt your events both in transit and a trust depending on the feature of your messaging broker. Because some messaging brokers have this feature to implement the encryption and all for intransit data and at rest, but some of them may not. So accordingly you have to choose the right one and implement the features that the particular router is giving or offering.

The next one is the cutting the IO or network cost because event driven architecture or the push based everything happens on demand as the event comes into the router. This way you are not paying for the continuous polling to check for an event. Like if you write a custom code, you have to keep checking, okay, is there an event and all right, it will be polling based. That is not needed anymore because the rotor will do a push mechanism. This means less network bandwidth consumption, less CP utilization and less SSL or TSL handshakes if it is on a secure protocol. Correct. So all this continuous resource consumption is reduced. So you’re saving a lot of resource cost in this manner because it’s a pushbased.

3. Example Architecture

So how it works. Here is an example you are seeing in front of you of an even driven architecture for the Ecommerce site or for our logistics company. Okay, here what you see is this architecture enables the site to react to changes from a variety of sources. One is like a retail website, one can be a mobile app and one can be a point of sale. So a particular retailer is coming from point of sale, someone is returning some item they purchased before in the point of sale and you may get a price question from the mobile app and there could be a new order from the retail website.

So all are like individual events, a new order is an event and a question about the stock is an event and the return order is an event. So the router is taking them and diverting accordingly to the consumers who are interested. So particular consumers like say if you see the database vera’s database WMS, it is interested in multiple events from different sources, it is interested in new orders, written orders as well as the availability of stock.

Whereas the financial system is only interested in the return order and the new order because it deals with the money, right? New order is like extra money, return order, detection of the money and the customer relationship system. CRM might be interested only in the question about the stock and the new order to answer about okay, what is the availability stock and is the new order we placed and all? Okay, so this way the example sees how it works. So the router will just ingest all the data coming in and upon injection it will filter out do according logic or the policies we applied and then divert the events or particular messages to individual consumers accordingly.

4. When to use EDA

So when to use this architecture? There can be many reasons. For example, you can use an event driven architecture to coordinate systems between teams operating in different regions or different accounts or different organizations. By using an event router to transfer data between systems, you can develop, scale and deploy services independently from the other teams. So you may not know in future what teams may come in or who are all will be interested in the particular event. So in that case, you will just write your logic or piece of work to just publish the event into the router tomorrow. Whoever comes in, they can subscribe and express their interest in this particular event and write their implement their logic accordingly.

And the next one is the resource state monitoring and alerting, especially for alerts and all. So rather than continuously checking on your resources, you can use an EDA architecture to monitor and receive alerts on any anomalies or changes or updates happening behind the scenes. Okay, so these resources can include things like any updates in the database background if you talk in the ERP perspective, any updates happening on the Europe in the background due to a batch update or any discrepancies, someone updating directly the stuff in the ERP which they are not supposed to do, or even WMS. Somebody’s tampering with the stock or the financial numbers, cost management, et cetera. So you can have alerts. Everything will emit an event, right? Any record change will emit an event. So you can express your interest religion to the event and write your logic employee accordingly to alert someone or notify someone.

One other scenario where you can consider this is if you have any fan out and parallel processing. So if you have a lot of systems that need to operate in response to a particular event, you can use an event driven architecture to fan out the event without having to write custom code to push to each consumer. Because like we discussed, there can be one event coming in, but rotor can multiply them and distribute to multiple consumers. So this router will push the event to the systems, each of which can process the event in parallel with a different purpose.

Like we saw, CRM purpose could be different, financial system purpose could be different, whereas management system purpose could be different in the previous example. So rotor can do all this stuff this way you will avoid a lot of repetitive coding by using the event driven architecture. And one more scenario to consider is the integration of heterogeneous systems. So if you have systems running on different stacks, you can use an event driven architecture to share information between them without coupling. The main intention is decoupling. So without coupling the systems, you can achieve the behavior with the EDA.

The event router will establish the direction of what events to go to, our system and all. So that like we discussed many times, this will decouple the system and the message exchanges will happen transparently without idea of the producer and consumers. Okay? So they will be agnostic to each other. The only messaging router will make sure that they are agnostic to the what systems they are being used in the organization. So if you have any question like should you use an event driven architecture in the first place, then there are some points you can actually consider to see, okay? Whether it is best fit for you or not. Generally even driven architectures are ideal for improving agility and moving very quickly.

They are commonly found in modern applications like I said before or any applications that has decoupled components. Okay? So when adopting an EDA, you may need to rethink the way you view your application design. It’s not like a typical Sava or API connectivity way. We will have a discussion in the coming lectures how this API electric activity and EDA go together. But in general the way of thinking or the application design has to change. It’s not a typical straightforward design when you take the EDA approach. So to set up yourself for a successful design and implementation of EDA, consider some pointers here.

The first one is the durability of your event source. Your event source should be reliable and guarantee delivery if you need to process every single event. Point number 1. Second point your performance control requirements. Your application should be able to handle the asynchronous nature of event routers. Because this is completely pub sub model, you won’t get the synchronous behavior. So your application should be ready for it and implemented accordingly to handle this synchronous nature by establishing some sync sync bridge and all to fulfill the requirement of interactive scenarios. Okay. Third one. Your event flow tracking indirection, introduced by an event driven architecture, allows for the direct tracking via monitoring services because, like, however, other consumers are consuming your events for the purpose of theirs, like CRM, WMS or ERP, you can have one more consumer whose job is to just consume and log it or audit it for molding purposes.

So this is possible. So you have to implement such kind of frameworks or things to have a custom logging and insights of the cow flowing events in the organization. The data in your event source is the next point if you need to rebuild the state. Your event source should be deduplicated and ordered because here the events flow in a particular order depending on the scenario, right? They can be parallely processed or they can be seriously obtained. So whenever you have to basically reprocess the data and all, you have to make sure that, okay, you take care of this exactly once processing and the serial order or the ordering of the messages because they cannot be guaranteed generally in the EDA, okay?

Unless the messaging broker has a specific feature or your rotor comes with a feature to provide these things, which is good in general and many of them generally give the feature these days. But most common messaging brokers does not give this exactly once. Processing or duplicate message processing or the order guaranteeing the order of the events. So they need to be taken care explicitly if not provided by the messaging brokers you are choosing. Okay, these are some things to keep in mind during the application design of EDA so that you have effective design and you don’t find issues coming into light in the later stages of the project. In the early stages. So let us move on to the next lecture in the course. Happy learning.