What is Event Driven Architecture?

An event is a state change or update, such as when an item is added to a shopping cart on an e-commerce website. EDA is a software design pattern that allows an organization to recognise "events" or critical business moments (such as a transaction, site visit, shopping cart abandonment, and so on) and act on them in real time or near real time. 

 

The previous "request/response" architecture, in which services had to wait for a response before moving on to the next job, is replaced with this pattern. Events control the flow of event-driven architecture, which is meant to adapt to them or take action in response to them.

 

Asynchronous communication is a term used to describe event-driven architecture. This eliminates the need for the sender and recipient to wait for each other to complete their next duty.

 

The systems aren't reliant on that one communication. A telephone conversation, for example, is considered synchronous or follows the classic "request/response" design. Someone calls and asks you to do something; the requestor waits while the responder completes the assignment; both parties then hang up. 

 

Text messaging is one example of asynchronous communication. You send a message, and you don't know who you're sending it to or whether anybody is listening in certain circumstances, but you're not waiting for a response.

 

A change in the status of a significant business system is characterized as an event. For example, someone may purchase goods, another may check in for a flight, or a bus may be late in reaching someplace. And, when you think about it, events happen all the time, no matter what business you're in. 

 

They may be found in any industry. An event is defined as anything that causes a message by being created, published, detected, or consumed. 

 

Because the event is the happening, and the message is the traveling notice that conveys the occurrence, the two are distinct. An event in an event-driven architecture is likely to trigger one or more actions or processes as a result of its occurrence.

 

Also Read | Introduction to Content Delivery Network

 

 

Evolution of Event-driven Architecture

 

There has been a shift in recent years away from focusing on data at rest (service oriented architecture) and toward focusing on events (event-driven architecture). We're focusing on data in flight and keeping track of it as it moves from place to place, rather than accumulating data and data lakes. 

 

Most systems work in what is known as a data centric model, in which the data serves as the source of truth. Moving from a data-centric to an event-centric approach is what event-driven architecture entails. Data is still vital in the event-driven paradigm, but events become the most significant component.

 

In the service-oriented approach, the most important thing was to make sure no data was lost. The aim with event-driven architecture is to ensure that you respond to events as they occur. 

 

When it comes to events, the rule of diminishing returns states that the older things become, the less useful they become. Service-oriented architecture and event-driven architecture, on the other hand, are frequently used together nowadays.

 

The log analogy is frequently used in event-driven architecture to keep track of things. Analysts refer to events as unchangeable occurrences. You may also go back and replay the log if you want to find out what happened in the past. In the data centric paradigm, you're primarily concerned with the current status of the data. 

 

Finally, when defining the differences between data-centric and event-centric designs, analysts frequently compare them to an information warehouse and a nervous system that transports signals across the organization.

 

When implementing an event-driven architecture, you'll have event producers that create and transmit event notifications, as well as one or more event consumers who receive the event and initiate processing logic. 

 

Let's pretend Netflix has just released a new movie. Several programmes may be listening or waiting for the notice, which would then cause their own internal systems to disseminate information about the occurrence to their users. 

 

In contrast to typical request-reply communications, apps continue to function and, while they may be listening for this event, they are not rendered inactive while waiting for it. They can also react once the message has been sent. As a result, many services can operate in parallel.

 

Also Read | Public Cloud: Working and Benefits

 

Working of Event Driven Architecture

 

An event-driven architecture may be divided into three parts: producer, consumer, and broker. When you have a single producer and a single consumer in direct connection with each other, and the producer just communicates the events to the consumer, the broker may be removed. 

 

A producer that simply sends to a database or data warehouse so that the events may be gathered and stored for analysis is an example. In most businesses, many sources are sending out various sorts of events, with one or more consumers interested in some or all of them.

 

Consider the following scenario. If you're a retailer, you could be tracking all of the transactions that take place at all of your locations throughout the world. You're feeding them into your event-driven architecture, which is looking for fraud and sending them to a credit card processor or whatever other steps are required. 

 

As a manufacturer, you have a lot of data coming off your equipment that tells you things like temperature and pressure so you can monitor these occurrences in real time and take actions like predicting problems or scheduling maintenance based on the data.

 

Event producers and event consumers make up event-driven architecture. An event producer detects or senses an occurrence and converts it into a message. It has no knowledge of the event's consumer or the event's conclusion.

 

After an event is identified, it is sent from the event producer to the event consumers through event channels, where it is processed asynchronously by an event processing platform. When an event takes place, event attendees must be notified. They may be processing the situation or simply being affected by it.

 

The event processing platform will respond to an event correctly and deliver the action downstream to the appropriate consumers. The consequence of an event is dealt with in this downstream action.

 

Apache Kafka is a widely used distributed data streaming framework for event processing. It can manage real-time posting, subscribing, storing, and processing of event streams. 

 

Apache Kafka offers a variety of use cases where high throughput and scalability are critical, and it may decrease latency to milliseconds by reducing the requirement for point-to-point interfaces for data exchange in specific applications. Other middleware event managers that may be used as an event processing platform are available.

 

Also Read | Latest E-commerce platforms

 

Event-driven Architecture Models

 

A pub/sub model or an event stream model can be used in an event-driven architecture.

 

1. Model of pub/sub

 

This is a communications architecture based on event stream subscriptions. After an event occurs or is published, this model sends an email to those who need to be notified.

 

2. Model of event streaming

 

Events are written to a log in an event streaming approach. An event stream is not subscribed to by event consumers. They can instead read from any portion of the stream and join it at any moment.

 

There are several forms of live event streaming:

 

• Event stream processing ingests events and processes or transforms them using a data streaming platform like Apache Kafka. In order to find significant patterns in event streams, event stream processing can be utilized.

 

• When an event causes an action in the event consumer, it is referred to as simple event processing.

 

• In order to find patterns, complex event processing necessitates an event consumer analyzing a sequence of events.

 

Benefits of Event-Driven Architecture

---

Benefits of Event-driven Architecture

---

 

1. A flexible system that can react to changes and make real-time choices may be achieved using an event-driven architecture. Real-time situational awareness means that any accessible data that represents the current condition of your systems may be used to make business choices, whether human or automated.

 

2. Event sources such as IoT devices, apps, and networks are collected as they happen, allowing event producers and consumers to transmit status and reaction information in real time.

 

3. Organizations may use event-driven architecture to increase the scalability and responsiveness of their systems and applications, as well as access to the data and context needed to make better business choices.

 

4. For data and applications, an Event-Driven Architecture is a contemporary design paradigm focusing on data that defines "events" (i.e., something that just happened). The taking of a measurement, clicking a button, or swiping a credit card are all examples of occurrences.

 

5. An event-driven architecture allows apps to react to events as they happen. This is in contrast to previous designs, which treated data as batches of data to be added and updated at regular intervals, and only responded to user-initiated queries rather than fresh data.

 

6. Events are created, detected, consumed, and reacted to in event-driven systems. Publishers, subscribers, sources, and sinks are all common ideas in event-driven systems.

 

The publisher is the component that collects and saves event data in a repository. The subscriber then consumes the event and may reply to it. Sources are the places that data comes from, while sinks are the places where subscribers transmit data.

 

7. You may produce and respond to a huge number of events in real time using a scalable event-driven architecture. Microservices, which are loosely connected software, benefit greatly from an event-driven design. Event-driven architectures are particularly adaptable because they operate well with unpredictable, non-linear occurrences. 

 

8. Applications may respond to data as it is created with an event-driven design. Because of the expansion of data sources that create events (IoT sensors, for example), as well as the creation and acceptance of technologies that handle event streams, such as Hazelcast Jet and Apache Kafka, the event-driven strategy has been highly popular in recent years. 

 

Instead of a handful of indicators on a weekly or quarterly report, organizations may view their operations and the data they create as a series of ongoing events using the event-driven approach.

 

Also Read | What are Point of Sale Systems?

 

Event producers generate a stream of events, while event consumers listen for the events in an event-driven architecture. Events are used to trigger and communicate between decoupled services or components in an event-driven architecture. 

 

Instead of polling for updates on a regular basis, EDA allows information to be sent across systems in real-time as events occur. It's found in a lot of current microservices-based apps.