{{announcement.body}}
{{announcement.title}}

Event Driven Architectures

DZone 's Guide to

Event Driven Architectures

Article all about Event Driven Architectures and how there are countless benefits of it creating decoupled, agile, flexible, scalable IT systems.

· Cloud Zone ·
Free Resource

Organizations are continuously modernizing their legacy systems to meet growing business needs, keeping up with regulatory mandates, technology advancements, and other changes to provide better customer experiences while attempting to lower the cost of ownership of IT systems. Event-Driven Architectures (EDA) are being adopted as a popular architectural design style to evolve the legacy architectures, especially in Financial Services. Wikipedia defines Event-Driven architectures as “a software architecture paradigm promoting the production, detection, consumption of, and reaction to events”.

Event-Driven Architecture is characterized by the notion of systems built around business events aka significant events in the lifecycle of business objects such as Trade Booked, Trade Validated, Trade Settled in a trading environment. Traditionally, systems have followed more of a request-oriented paradigm which leads to greater coupling among systems and results in monolith systems which are hard to evolve with the constant changes. In typical monolith systems, there is typically no clear separation of business domains/objects and the various states those objects go through in the fulfillment of a business process. State changes of these business objects typically happen in a batch manner constraining the system itself and providing limited visibility to the business on the real state of a “transaction” at any given time. Event-Driven Architectures that allow for the state changes to business objects exposed as events for consumption by interested parties provide businesses the ability to get near-real-time visibility to the state of business events as they happen and the ability to react to those events in a timely fashion.

EDA promotes the development of decoupled systems aka systems that are built with small, function-specific components often implemented as Microservices. Adopting an architecture based on events and Microservices allows a platform to be created out of small “chunks” where individual components can provide discrete functionality, scale independently and communicate with other parts of the platform in a decoupled manner by publishing and subscribing to events of interest. The separation of concerns between publishers and subscribers promotes the idea of decoupled systems.

A big question in people’s minds is will an event-driven architecture scale, especially in industries where transaction volumes are high and low latency is required? The simple answer is yes if designed properly with the appropriate non-functional requirements factored in the design early-on. Data consistency is another issue that often is raised as a concern with EDA. The key message to remember is that in EDAs the goal should be that of eventual data consistency – clearly defining the source of truth is very important when designing architecture around events. The ability to persist and playback events in the sequence they happened is another key aspect of such an architecture with an event fabric backed by an event store key pieces of the architecture. 

Successful EDAs start with modeling the significant business items/objects/domains and determining what states are important from a business perspective. These form the basis of the event catalog. Event storming is a technique that can be used to facilitate the discovery of significant business events.  An illustrative example of a business information model to carve out the domains is shown below.

business information model to carve out domains

 

The following diagram illustrates how a trade transaction can go through several state changes based on the business process flow and how each state change results in an event being published and consumed by other services for further processing.

how a trade transaction can go through a number of state changes based on the business process flow

A key consideration, when defining an architecture based on events is defining the event schema in a standard manner considering the need for providing traceability, data-lineage, etc. in a real-world scenario. Event payloads may evolve over time and hence the need to plan for versioning capabilities to allow for consumers to continue to work uninterrupted. Given the proper considerations around non-functional characteristics of the system, an EDA can indeed provide the promised benefits of decoupled, agile, flexible, scalable IT systems.

Topics:
event driven architecture, microservice

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}