Event-Driven Architecture Style
Event-Driven Architecture Style

Request Based Models

Request based models is basically the handling of requests sent to a system and handling of this requests is done by the request processor. Request processors handle requests by performing CRUD on a database(retrieving and updating info on a database). The requests sent to the RPs are sent by the Request Orchestrator and ROs synchronously sends data to RPs.

A good example of the request-based model is a request from a customer to retrieve their order history for the past six months. Retrieving order history information is a data-driven, deterministic request made to the system for data within a specific context, not an event happening that the system must react to.

Another example of the request-based model is a request by a shop owner to retrieve the available stocks in the inventory.

Event Based Models

Event based models is handling of a situation where an event occurs and the system takes an action based on that event.

An example of an event-based model is submitting a bid for a particular item within an online auction. Submitting the bid is not a request made to the system, but rather an event that happens after the current asking price is announced. The system must respond to this event by comparing the bid to others received at the same time to determine who is the current highest bidder.

Another example is logic of a Recommendation Engine. Spotify improves itself based on actions taken by an event of when a user likes a particular music and brings similar genres to the user based on this event.

Topologies in Event-Driven Architecture

There are two: Broker Topology and Mediator topology.

Mediator Topology

In Mediator topolgy, the central event mediator manages and controls the workflow for initiating events that require the coordination of multiple event processors. The architecture components of this topology are: initiating event, an event queue, an event mediator, event channels and event processors.

Intiating event is the event that starts the process, this event is now sent to an event queue which is accepted by the event mediator. Event mediator generates corresponding processing events that are sent to event channrld. Event processors then listen(eavesdrop) to event channels, process the event and respond to mediator they have completed their work.

Event processors don't advertise what they did to the rest of the system. That's done in broker topology.

For example, there might be a customer mediator that handles all customer-related events (such as new customer registration and profile update), and another mediator that handles order-related activities (such as adding an item to a shopping cart and checking out).

Example of mediators include Apache Camel, Mule ESB for simple error handling and orchestration and for event workflows that require lots of conditional processing, Apache ODE, Oracke BPEL are good examples of mediators.

You should classify events as simple, hard or complex and you can do this with a simple mediator(Apache Camel). If a task is simple, it gets sent to the event channel and then event processor. If it's hard or complex, it's sent to event queues which then seperate it to BPEL or BPM(Business Process Execution Language and Business Process Management).

Mediator component has knowledge and control over the workflow: think of the retail ordering system(Jumia) and this makes it capable of maintaining event states, manage error handling, recoverability and restart capabilities.

⁠

Broker Topology

Here, there's no central event mediator, instead the message flow is distributed across the event processor components in a chain-like broadcasting fashion through a lightweight message broker. Example of message brokers include RabbitMQ, ActiveMQ, HornetQ, etc. Architecture components in broker include: initiating event, the event broker, an event processor and a processing event.

An initial event starts the entire event flow and this event is sent to an event channel in the event broker for processing. The event processor then acccepts the event from event broker, processes the event and then asynchronously advertises to the rest of the system it has performed the task associated with initiating event. This advert is called a processing event and this new event is them asynchronously sent to the event broker for futher processing and the event processors listen and react to this processing event if needed.

A wild guess example of broker topology: when you set a recovery email for a gmail account, any signin attempt is recorded and sent to the email you're trying to signin and to the recovery email. If further processing is needed, you create a new event by clicking the link to stop unauthorised signin. But advertisement is always done.

Think of broker topology as a relay race, you pass the baton and you're done.

The choice between the broker and mediator topology essentially comes down to a trade-off between workflow control and error handling capability versus high performance and scalability. Although performance and scalability are still good within the mediator topology, they are not as high as with the broker topology.

Asynchronous Capabilities

Event-Driven architecture relies solely on asynchronous communication for both fire and forget processing as well as request/reply processing. The former is when no response is required(broker topology) and the latter is when reponse is required from the event consumer(mediator topology). This feature makes a unique characteristic over other architecture styles. Asynchronnous communications improves reponsiveness significantly but the main issue with it is error handling. This can be addressed with a pattern of reactive architecture called workflow event pattern.

Error Handling

Workflow event pattern addresses issues associated with error handling in an asynchronous workflow. A system can be resilient in terms of error handling without impact to responsiveness in this reactive architecture pattern. An example is the trade placement example.

Preventing Data Loss

Data loss is defined as a message getting dropped or never making it to its final destination. Asynchronous communication always deal with data loss, hence event-driven architecture is culpable to data loss. To mitigate data loss, we use basic messaging techniques: synchronous send and persisted message queues. The latter involves storing messages in memory and a physical data store while the former does a blocking wait in the message producer until the broker has acknowledged that the message has been persisted.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Event-Driven Architecture StyleEvent-Driven Architecture Style