We previously spoke about the need for using multiple applications and API Integration. Following up on our previous blog about Middleware and EDA, this post will be focusing on events, and event processing styles. 

What is an event?

An event is a change of state for a key business system. Events exist everywhere and are constantly happening. They’re pervasive across businesses. This includes anything that makes a message by being produced, published, detected, or consumed. The event breaks away the message, because while the event is at occurrence, the message travels with notification relaying on the occurrence. In event-driven architecture, an occasion will likely trigger one or more actions or processes in response to its occurrence. An example of an occasion might include:

• Password reset request
• Package being delivered to destination
• Inventory updates by a grocery warehouse
• Unauthorized access attempt denied

Each of these events is probably going to trigger one or more actions or processes in response. One response could be simply to log the event for monitoring purposes. Others might be:

• Password reset email being sent to the end user
• Sales ticket being closed
• Ordering products to replenish inventory

With event-driven architecture, when an occasion notification is shipped, the system captures that something happened, and it sort of changes the state in which it has occurred and waits to send the reply to whoever requests it, whenever they request it. The appliance that received that message can either respond or wait to reply until the expected change in state has occurred. Applications which are built around EDA enable agile, scalable, contextual, and responsive digital business applications. Simply put, the event may be a significant change in state, which is triggered when a user takes an action. For example: When a customer buys a car and its state changes from purchasable to sold is an occasion. After a successful transaction, when an amount gets deducted from your account is an occasion. Once clicking on the book cab button, when a cab is booked from your account is an occasion. Every event may trigger one or more than one response options.

Event Processing Styles: 

Here are the different types of event processing: 

Simple event processing

Simple event processing directly associates with specific, measurable changes of condition. In this processing, a notable event happens which initiates downstream actions. Simple event processing usually drives the real-time flow of labor, thereby reducing lag time and price. For example, simple events are often created by a sensor detecting changes in tire pressures or ambient temperature. The car’s tire’s incorrect pressure will generate an easy event from the sensor which will trigger an  indicator advising the driving force about the state of the tire.

Event stream processing

In event stream processing (ESP), ordinary and notable events can happen simultaneously. Ordinary events (orders, RFID transmissions, etc.) are screened for notability and streamed to information subscribers. Event stream processing usually wants to drive the real-time flow of data in and round the enterprise, which enables timely decision making.

Complex event processing

Complex event processing (CEP) allows patterns of straightforward and ordinary events to be considered to infer that a posh event has occurred. Complex event processing evaluates a confluence of events, and  then takes action. The events (notable or ordinary) may cross event types and occur over an extended period of your time. The event correlation could also be causal, temporal, or spatial. CEP requires the utilization of sophisticated event interpreters, event pattern definition and matching, and correlation techniques. CEP usually wont detect and answer business anomalies, threats, and opportunities.

Online event processing

Online event processing (OLEP) uses asynchronous distributed event-logs to process complex events and manage persistent data. OLEP allows to reliably compose related events of a posh scenario across heterogeneous systems. It enables extremely flexible distribution patterns with high scalability and strong consistency. However, it cannot guarantee a boundary to the time interval.

Pub/sub model

This is a messaging infrastructure supported subscriptions to an occasion stream. With this model, after an occasion occurs, or is published, it’s sent to subscribers for acknowledgement.

How does Event-driven architecture work?

The components of an EDA can include three parts: producer, consumer, and broker. The brokers are often optional, particularly once you have one producer and one consumer that are in direct communication with one another and therefore the producer just sends the events to the buyer. An example would be a producer that’s sending only to a database or data warehouse therefore the events are collected and stored for analysis. Most ordinarily in enterprises, you’ve got multiple sources sending out all kinds of events with one or more consumers curious about some or all of these events.

Let’s check out an example. If you’re a retailer, you would possibly be collecting all of the purchases. You’re feeding them into your event-driven architecture that’s expecting fraud, sending them to a mastercard processor or any other actions that may occur next. For a manufacturer, you’ve got all types of knowledge coming off your equipment that’s telling you facts like temperature and pressure so you’ll monitor these events in real-time and take actions like predict failures or schedule maintenance, based on the information available with you.

Benefits of Event-driven Architecture

• Adding new events and processes is extremely easy within the event-driven architecture.
• You can quickly roll-back changes or move to any event within the event-driven architecture. This is helpful in case there are any issues.
• Event-driven architecture also gives you transactional guarantee, i.e., you’re notified of each successful transaction as it happens.
• The architecture is flexible and replaceable.
• EDA is very responsive. Rather than expecting issues to occur, you’ll easily detect them beforehand – thus ensuring that the app keeps working.

Develop with agility

You do not have to write custom code to poll, filter, and route events; the event router will automatically filter and push events to consumers. The router also removes the necessity for heavy coordination between producer and consumer services, speeding up your development process.

Audit with ease

An event router acts as a centralized location to audit your application and define policies. These policies can restrict who can publish and subscribe to a router and control which users and resources have permission to access your data. You’ll also be able to encrypt your events both in transit and at rest.

Cut costs

Event-driven architectures are push-based, so everything happens on-demand because eachevent presents itself within the router. This way, you’re not paying for continuous polling to look out for an occasion. This requires less network bandwidth consumption, less CPU utilization, less idle fleet capacity, and fewer SSL/TLS handshakes.

Scale and fail independently

By decoupling your services, they’re only conscious of the event router, not one another. This suggests that your services are interoperable, and  if one service fails, the others  continue running. The event router acts as an elastic buffer which accommodates surges in workloads.

Parting Thoughts:

Like this blogpost? Checkout the first part of this blog here and know more about Middleware platforms and EDA. If you are interested in our API Integration services, visit our Contact Us page for more details.