Data is produced daily from countless sources such as updates from sensors, clicks on a website, or internal inputs that applications need to keep up with. Keeping up with an endless stream of new events requires businesses to design applications with events at the core of systems.
Events record state changes or something that has happened. They can’t be modified and are ordered based on their sequence of creation. Users subscribe to published events that notify them of state changes so they can act on the event notification with business logic. Event driven architecture (EDA) is a system of loosely coupled microservices that communicate through the production and consumption of events. EDA uses either a traditional publish-subscribe message broker or a distributed log to transmit messages from producers to consumers.
A publish-subscribe message broker sends a message from a producer to multiple consumers subscribed to groups of messages. These one-time delivery messages don’t require an action and are often deleted after receipt. A distributed log is an indefinite set of ordered events. Events in an event stream can be replayed because all data is kept indefinitely.
A closer look at events.
Anything that creates a message by being produced, published, or consumed is an event. An event, which is the occurrence, is separate from the message, which is the notification that replays the occurrence. A simple event can initiate one or more actions or processes as a response to the occurrence.
Common examples of simple events include a password reset request, the notification that a package has been delivered to its destination, an update to inventory, or the denial of an unauthorized access attempt. These simple events, in turn, trigger specific tasks or processes in response such as sending a password reset email, closing the sales ticket, placing an order for more inventory, or locking an account.
Event notifications trigger the system to note that a state change has occurred and waits to send a response to whoever requests it at the time of the request. The application receiving the event message can respond or wait to respond until it detects the state change. Applications based on EDA allow for the agility, scalability, context, and responsiveness of digital business applications.
The three key components of event-driven architecture.
Event-driven architecture frameworks have three key components: event producers, event consumers, and a broker. Event producers publish an event to the router which then distributes events to event consumers. Producer and consumer services are decoupled so they can be scaled, updated, and deployed. Businesses typically have multiple event sources that send all types of events that pique the interest of event consumers.
What are the benefits of event-driven architecture?
Event-driven architecture allows websites to react to real-time changes from a variety of event sources during times of high consumer demand without latency or crashing the application. Decoupling your services leads to scalability as they are interoperable, but in the event one service fails, the rest won’t be affected. The broker automatically filters and distributes events to event consumers without the need for custom coding, speeding up the development process.
An event broker is a centralized hub that audits applications and defines policies. Such policies restrict who can publish and subscribe to an event channel and who has access to data. An event architecture pattern is push-based, meaning everything is on-demand as the event is sent to the broker. This eliminates the need to constantly monitor for updated event messages and cuts the associated costs.
The evolution of event-driven architecture.
In recent years there has been a shift from focusing on data at rest, known as service-oriented architecture, to focusing on events, known as event-driven architecture. The focus is going from accumulating data and subsequent data lakes to focus on distributed data and tracking it in transit. Most systems operate on a data-centric model that relies on data as the source of truth. Event-driven architecture operates on an event-centric model that prioritizes real-time responses. The drawback to EDA is that events lose value the older they become.
It’s becoming increasingly common for businesses to explain their data-derived decisions. The log of unalterable events provided by EDA is essential to auditing since it can be replayed on-demand. The architecture pattern is useful for building a resilient microservice-based architecture that is agile, accessing event streams for real-time decision making, and for accelerating the adoption of machine learning.
