Event-driven architecture (EDA) is a software design pattern that uses events to trigger actions between decoupled components. It's a popular choice for building scalable, distributed systems.
EDA is commonly used in modern applications built with microservices. It's also used in real-world applications like Fraud detection, Internet of Things (IoT), Payment processing, and Real-time marketing. EDA is a programming approach, not a language, so event-driven apps can be created in any programming language. EDA's two main patterns for transmitting events are publish/subscribe and event streaming.
What does the term "event" mean in EDA?
A change in state is called an event. In an event-driven architecture, everything that happens within and to your enterprise is an event — customer requests, inventory updates, sensor readings, and so on.
How does an EDA work?
In an event-driven architecture, applications act as event producers (apps that produce or capture events) or event consumers (apps that process and act on events). Producers transmit events to consumers via a broker, aka messaging-oriented middleware, in real time. Consumers can then process the event and trigger other actions, workflows, or events of their own.
In a very simple architecture – when there is a single producer and a single consumer that are in direct communication with each other – brokers can be optional. However, in most enterprises, there are multiple sources sending out events to multiple consumers, so a broker or even a network of brokers (also known as an “event mesh”) is needed. When a broker or an event mesh is used, this creates a “loose coupling” of applications.
Event-driven architecture patterns
There are two main patterns for transmitting events in an event-driven architecture: publish/subscribe and event streaming.
Publish/subscribe (aka “pub/sub”) – With pub/sub, event consumers subscribe to messages and channels published by event producers. When an event is published, it is sent directly to all subscribers via a broker. To avoid duplication, events cannot be replayed or accessed once consumed – they are deleted by the broker.
Event streaming – With event streaming, producers publish entire streams of events to a broker. Consumers subscribe to the stream and can read from any part of it, consuming only the events that are relevant to them. With this pattern, events are retained by the broker even after they are consumed.
Event-Driven Architecture Use Cases
Let's consider a scenario. We have an Online Mart where we pick products and put them in it our specific cart. Once we are done with our shopping, then we move toward the checkout process to proceed with the payment process.
Within this check out to Payment process, there are various minor activities that need to be handled simultaneously which get triggers only when the particular event/action occurs.
Pre-requisite
VS-2022
Create a Web API project.
Create an EventBus Class, in which we delegate the methods to perform whenever it calls.
We have a set of repositories to function their respective operations accordingly. This delegate points those methods in between any action occurs to perform the minor task after any event occurs.
Let’s run our application and look out for the series of activities that take place after a single event.
Check out the Event, complete with follow operations like inventory check and validating the stock. Now, we will call the next event to pay for the selected items in the carts.
Once the Payment is done, Inventory details are updated for items that get sold. Confirmation Notification will be sent via email.
In the above example, within 2 events, we are executing corresponding functionalities such as.
- Check Out: Validate Stock Availability
- Payment
- Update Stock Detail.
- Send Notification for sold item to refill.
- Sent a mail confirmation of the order to the customer’s email ID.
Benefits of an Event-driven Architecture
There are many benefits of an event-driven architecture. The top 3 are,
- Real-time workflows and responsiveness: An EDA can monitor and quickly react to events as they occur, often using robotic process automation (RPA) to accelerate workflows and trigger next steps in real time. This is especially critical during times of peak demand – for example, during major sales events or holidays. This responsiveness can also be applied to everyday (i.e., non-peak) workflows, improving everything from supply chain automation to fraud detection.
- Asynchronous messaging: Applications in an EDA communicate asynchronously – meaning producers publish event messages without waiting for consumers to receive them. Not only does this let applications move on to other tasks without waiting, but it also simplifies integration.
- De- and loose coupling: Applications in an EDA are de-coupled or loosely coupled and are not dependent on each other’s availability. They can be updated, tested, and deployed independently. They can also fail independently, so the architecture is more durable and persistent than traditional models. Decoupling also makes it easy to add extra publishers and consumers as needed, eliminating the need to rewrite code every time there is a change.
- Reliability and Fault Tolerance. EDA enhances system reliability and fault tolerance by leveraging event-driven communication. Events can be logged and stored in a durable event store, providing an audit trail of past events. This allows for error handling, recovery, and replaying of events, ensuring fault tolerance and system resiliency. In the event of failure, components can be restored to a consistent state by replaying the events, providing a reliable and consistent system.
Takeaway
Event-driven architecture is a way of designing systems that make your applications more flexible and able to grow without problems across your business. Although this method can bring some new difficulties and complexities, it’s a good way to create complicated applications by allowing different groups to work on their own. Some cloud services even provide managed tools that can help your organization build these kinds of architectures.
Join the conversation! Your thoughts help the community grow.