introduce

The event-driven architecture pattern is a well-known distributed asynchronous architecture pattern for building highly extensible applications. This architecture applies events to triggers and interactions between decoupled services and is popular in modern applications developed with microservices. You can see an event-driven architecture in the shopping cart of an e-commerce site. Such as adding items to shopping cart, product price changes, checkout, payment, shipping, delivery notice, etc. This architecture helps applications respond to changes from a variety of sources during periods of high concurrency without impacting the application or overconsuming resources.

Event-driven architecture has multiple benefits. It facilitates the implementation of events across multiple services and provides ultimate consistency. Another benefit is that it also allows applications to maintain materialized views.

Topology of event-driven architecture

Understanding the topology of event-driven architecture is important to delve into the sub-patterns of event-driven architecture. The architectural pattern is based on two main topologies:

  • Mediator
  • Broker

Mediator

Mediators play an important role in Mediator topology. It is often used when steps need to be coordinated with events through a central mediator. This is helpful for events that have multiple events and require some degree of choreography to handle them.

Example: Designing a GPS program in a vehicle

GPS data is considered an appropriate GPS starting point for designing a vehicle for overall safety, navigation, and cost estimation planning. They are designed to provide appropriate business and security objectives. It involves the following steps:

  • Off-road Vehicle Tracking: An OFF-road vehicle is any type of vehicle capable of driving expertly on paved or gravel surfaces. GPS data can provide the vehicle’s data and the corresponding channel will trigger analysis for further details.
  • Travel time estimation →GPS provides travel time estimates from one location to another, and this data can be further used to analyze time-related business impacts.
  • Navigation to destination → this is very helpful for logistics companies. Logistics companies use telematics to improve driver productivity and safety. This concept can be used to support route optimization, fuel efficiency, driver safety and consistency

All of these steps require some degree of coordination to determine the fitness goal steps, and they can be done consecutively and in parallel. There are four components in the mediation topology:

  • mediator
  • The queue
  • channel
  • The processor

mediator

The mediation component acts as the coordinator for each initial step. It identifies the event type or data type and sends it to a specific channel.

There are several tools for dealing with mediation topologies. Examples :jBPM, Mule ESB, Apache Camel, Spring Integration, etc.

The queue

There are several tools for dealing with mediation topologies. Examples :jBPM, Mule ESB, Apache Camel, Spring Integration, etc. There are several tools available to deal with mediation topologies. Examples :jBPM, Mule ESB, Apache Camel, Spring Integration, etc.

channel

Event mediations use event channels to pass specific events related to each step in the main event to event handlers. It can be a message topic or a message queue.

The processor

It is a component or service application that contains business logic that performs business requirements when events are received. These are now microservices-based components. It can also be a channel queue consumer.

Agent topology

In a Broker topology, message flows are distributed among event handlers as they receive events. It is different from the mediator because it is not the center. It is useful in chain processing.

For example: Designing an online ordering system, which is the process of ordering food on a website or app. When a user orders a meal online from an application or website, it generates an event and message flow to different events to complete the ordering process. It’s a chain of different processes:

  • The user selects the restaurant and orders the food.
  • Pay for ordered food.
  • The restaurant was notified
  • Delivery partners are notified
  • Restaurants turn over food to delivery partners
  • Delivery Partners deliver food to users

In the above architectural design, links can be used to satisfy business functions. Queuing mechanism has also been introduced to make it more scalable and accurate. This topology is common when an application is evolving or providing future functionality and extensions.

conclusion

Event-driven architectures are popular because of their high scalability and distributed asynchronous behavior. It is well suited to microservice architectures and provides highly decoupled systems.

More exciting content pay attention to the public number [programmer Shi Lei]