Quality
10 min
Meaning of Code Audit ⎻ When and Why We Need It
View more
April 20, 2022
Success Story
4 min
GRDF: Shifting to SAP Fiori and giving customers a better digital experience
View more
June 8, 2021
Event-Driven-Architecture (EDA) is an application development concept that allows systems to respond to an "event" in real-time or as near to real-time as feasible.
In modern application event-driven architecture is built with microservices and it works by using events to trigger and communicate between disconnected services.
An event occurs when a change in state happen, or an update for instance when an item is placed for order in a shopping cart on an e-commerce app.
Placing the order triggers an event that represents the fact that some action took place.
An event-driven system consists of three critical components that react to the event:
Consider the following example:
Event Producer: When a customer places an order on an eCommerce site, a "Check Out" event is generated, which is forwarded to an event broker.
Event Broker: The event broker makes the event available to event consumers listening or waiting for "Check Out" type events to occur.
Event Consumers: Services such as "Stock" and "Communication" are examples of event consumers.
The "Stock" service determines whether or not an item is in stock. If the item is in stock, an event is created and consumed by the "Communication" service, which sends a message to the customer informing them that their order is being processed, with a second message sent when the goods are shipped.
If an item is out of stock, the "Communication" service informs the customer that they can either wait for it to come back in stock or cancel their order.
When an item is dispatched, the "Shipping" service generates an event that is consumed by the "Communication" service, which delivers a message including information such as the package tracking number, the date it shipped, and the expected delivery date.
According to Gartner;
“As the mastery of event-driven architecture is essential to digital business and achieving this mastery is a multistep process, application leaders — still lacking a plan of action for strategic use of EDA — must begin now.”
Why? Because event-driven architectures are more scalable than traditional approaches, enabling larger systems with faster response times.
Event-driven architecture is a perfect fit for companies embracing digital transformation. EDA helps companies build complex event processing with the flexibility, speed, and agility needed to keep up with the pace of innovation.
Here is a quick guide on event-driven architecture and why it is ideal for modern system design and development.
Over the last few years, there has been a shift away from focusing on data at rest (service-oriented architecture) to focusing on events (event-driven architecture).
More and more companies are shifting away from accumulating data and data lakes. Instead, they see more value in focusing on data in flight and tracking it as it moves from place to place.
An event-driven architecture can be divided into three components: producer, consumer, and broker. The producer is the system, often an API, that sends events.
The consumer receives notifications of new events. The broker is responsible for coordinating sending events to the consumers.
The broker is optional when you have a single producer and a single consumer in direct connection with each other. In this case, the producer sends the events to the consumer.
An example would be a producer who only sends to a database or data warehouse so that the events can be gathered and saved for analysis.
Unlike standard request-reply systems, each component of an event-driven system can continue to function while waiting on events using what is referred to as asynchronous processing.
An event is defined as a change in the state of a business system. An event is anything that generates a message by being created, published, detected, or consumed.
The event is distinct from the message because, although the event is happening, the message is the notice that conveys that the event took place.
In an event-driven architecture, an event will almost always trigger one or more actions or processes in reaction to its occurrence. An example of an event could be, requesting a password reset.
One possible reaction is to simply log the incident for future reference. Another reaction could be to send an email confirmation to the user requesting to reset their password.
When an event notification is issued in an event-driven architecture, the system captures the event. Applications(consumers) who need the information can choose to receive the notification instantly or they can choose to request it as needed.
Event-driven architecture-based apps offer more agile, scalable, contextual, and responsive digital business solutions.
They are also perfectly suited for systems with real-time or near real-time data processing use cases.
The mediator and the broker are the two major topologies used in event-driven architectures. The mediator is used when various phases of an event must be orchestrated through a central mediator.
When events and responses must be chained together directly without the assistance of an intermediary, the broker topology is utilized.
This event-driven topology is better suited for more complicated situations involving multiple stages to process an event that requires event processing orchestration.
The queue, the mediator, the channels, and the processors are the four essential components of the mediator topology.
An event sends a message to a single event queue via a pre-processing event pipeline, which transports the event to the mediator.
This establishes an event stream that distributes events to consumers. The mediator orchestrates the process by passing asynchronous events to numerous event channels that perform a separate phase of the process.
Meanwhile, the event consumers are listening and waiting to receive events from the mediator. They then apply the necessary business logic to process them.
The broker topology is best suited for basic event streams that do not need event orchestration. There is no need for a mediator, therefore, it can be centralized.
The only essential components are the broker and the consumer. There is no event queue or mediator.
It is up to the event producers to get each event, publish it and send another event that indicates the completion of processing.
The tasks are all asynchronous to maintain the loosely connected nature of Event-Driven Architecture. Adservio helps customers design event-driven architectures with the topology best suited for optimal performance.
There are two types of event-driven architecture models. It can be either a pub/sub model or an event stream model.
Event-streaming systems, like message-oriented systems, convey messages from an event sourcing system to decoupled target systems.
Instead of sending each message to a process-specific queue, event-based systems typically publish messages to a shared topic. One or more consumers subscribe to that topic to listen for relevant events.
The messaging system does not need to know anything about the subscribers under the pub/sub paradigm. Consumers keep track of which messages they have received and are in charge of self-managing load levels and scaling.
In event-streaming systems, calls are usually always asynchronous; they deliver events without waiting for a response.
Asynchronous eventing provides more scalability choices for both producers and consumers. However, if you want FIFO message-order guarantees, this asynchronous style can cause problems.
Event Stream Processing: This approach uses a data streaming platform, such as the open-source software Apache Kafka, to ingest events and process or transform the event stream.
Event stream processing can be used to detect meaningful patterns in event streams. This type of stream processes data sequentially and conducts real-world aggregation and correlation, filtering, or sampling.
Event-driven architecture is ideally suited for today’s modern applications that require real-time or more complex workflows. The approach has several advantages which include:
Components of EDA-based systems are loosely connected. This facilitates the logical separation of event creation and consumption.
Producers are unconcerned about how events are consumed and consumers are unconcerned about how events are produced.
Loose coupling aids in scaling because producers and consumers can be added or removed as needed without causing logical changes in the other components of the system
Eventing is asynchronous (as opposed to synchronous), which means that events are published as soon as they occur.
If any consumer fails, the application will continue to function without it. Events are queued in the broker so that the consumer can pick up the pending events when it recovers from the failure. Agility In Development
You no longer need to write custom code to poll, filter, and route events; the broker will filter and transmit events to consumers automatically.
The broker also eliminates the need for extensive coordination between producer and consumer, giving you the agility to accelerate your development process.
Because event-driven architectures are push-based, everything happens as soon as the event appears in the router.
You won't have to pay for continuous polling to check for an event. This translates to decreased network bandwidth, lower CPU use, less idle fleet capacity, and fewer SSL/TLS handshakes.
All of this equates to cost savings in a cloud-based processing environment.
Digital transformation requires speed and agility. Companies looking to remain competitive in this new landscape must adopt new methods to keep pace.
A recent report from Coleman Parkes discovered that the majority of organizations, 85 percent, recognize the critical business value in adopting event-driven architecture.
If this describes you and you are looking for help with implementing an event-driven architecture, reach out to our team of professionals.
Build your modern system designs with event-driven architecture and turn them into a robust, resilient and highly scalable apps.
.png){kind=logo}
.jpg)
-min.jpg)