by: VMware Enterprise Integrations Architect Jitendra Nath and VMware Technical Architect, Business IT Architecture Eric Rong
What is event-driven architecture?
Event-driven architecture (EDA) is a software design pattern that revolves around the idea of reacting to events triggered by changes in the system or by external stimuli. Events can be anything from user interactions, changes in data, system notifications, or external events like application programming interface (API) calls or messages from other systems. In an EDA, components of a system communicate with each other by producing and consuming events, allowing for loose coupling and scalability.
Components in an EDA are organized into producers and consumers. Producers generate events and publish them to an event bus, which acts as a communication channel. Consumers subscribe to the event bus and receive events they are interested in. This decoupling between producers and consumers allows for flexibility and extensibility in the system, as components can be added or removed without affecting other components. See Figure 1.
There are several key concepts that make up EDA. These include:
- Events – Events are the building blocks of EDA. They represent a change or a notification about something that happened in the system. Events can be simple, such as a button click event in a user interface, or complex, such as a message received from an external system.
- Event Bus – The event bus acts as a central communication channel that allows events to be published by producers and consumed by users. It can be implemented using various technologies, such as message brokers, publish-subscribe (pub/sub) systems, or event-driven frameworks.
- Producers – Producers are components that generate events and publish them to the event bus. They are responsible for detecting changes or triggering events in the system and making them available for consumption.
- Consumers – Consumers are components that subscribe and react to events on the event bus. They perform actions based on the events they receive, such as updating data, sending notifications, or triggering other events.
- Event Handlers – Event handlers are responsible for processing events and executing the appropriate actions. They receive events from the event bus and contain the logic to respond to events based on predefined rules or business logic.
Event record design consideration
An event record captures the data related to an event. In contrast to traditional API-style interaction (“request/response”), the event record conveys facts—the action taking place and the result of the state of the system. The consumers, and what they may do with the information, is irrelevant.
EDA Patterns
There are three main patterns that convey facts/state using the event record.
Full state pattern
In full state pattern, the event record contains all the information regarding the result state of actions that happen on the producer side. The consumer can deduce all needed from just the event record itself. See Figure 2.
Pros of full state pattern
- No additional interaction is required between producer and consumer.
- The producer does not need to maintain any of the intermediate states as action occurs.
- The consumer will receive every single intermediate state that happens on the producer side as each action occurs.
- Can reliably recreate the state of the system at any point of time.
Cons of full state pattern
- There is a bigger payload.
- Maintaining the order of the events becomes critical
- Some packaged systems may not be able to implement this pattern out of the box
Notification Pattern
In the notification pattern, the event record contains the necessary identification information of the object carries the state regarding the result state of some action occurred on the producer side. Consumers need to perform additional action to retrieve the state using alternative means (API call). See Figure 3.
Pros of notification state pattern
- Smaller payload
- The order of the events may not be super critical
- The consumer will always get the latest state, regardless of how many intermediate state transitions happen
Cons of notification state pattern
- Additional interaction/coupling is required between producer and consumer.
- It is difficult to get/create an intermediate state of the system unless producer maintains it separately
In partial state pattern, the event record contains part of the resulting state of some actions that occurred on the producer side. Usually, it contains information relevant to most of the consumers. Upon receiving the event record, the consumer can process the event directly, which will perform additional actions required to retrieve extra state information. See Figure 4.
Pro of partial state pattern
- A fine balance between the “full state” pattern and “notification” pattern
Con of partial state pattern
- Depending on the consumer needs additional interaction/coupling may still be required.
EDA Benefits
Scalability – Event-driven architecture allows for horizontal scalability, as components can be added or removed independently without affecting other components. This makes it suitable for handling large volumes of events and distributed systems.
Flexibility – Event-driven architecture promotes loose coupling between components, allowing for changes or updates to be made to one component without affecting other components. This makes it easier to extend or modify the system in the future.
Responsiveness – Event-driven architecture enables real-time or near real-time processing of events, allowing systems to react quickly to changes or external stimuli.
Resilience – Event-driven architecture can provide fault tolerance and resilience, as events can be persisted or replayed in case of failures, ensuring that events are not lost.
Modularity – Event-driven architecture promotes modular and decoupled components, making it easier to develop, test, and maintain individual components.
The Challenge
To design a good event-driven architecture system, the components described above must be designed adequately, which requires a considerable effort across teams, increasing the time to market.
To overcome the challenges of managing and maintaining the event-driven platform, we built the VMware Event Hub™ to simplify event management and event-driven architecture adoption across broader teams.
VMware Event Hub
VMware Event Hub is an event streaming platform based on event-driven architecture (EDA). It reduces point-to-point integrations and helps design decoupled systems. It allows us to scale up events generated from applications, integrated systems, and services. See Figures 5 – 7.
VMware Event Hub Features
Publisher/subscriber broker – allows services to publish/subscribe to events and provides a reliable delivery mechanism of the messages from publishers to subscribers.
Publisher/subscriber registry services – HTTP-based, supports the registry of publisher/subscriber for specified events and the ability to unsubscribe.
Publisher/subscriber, authentication/authorization services – supports authentication/authorization mechanism for the publisher/subscriber.
Publisher event registration – supports registry of event schema based on enterprise standards and delivery quality of service (QoS—guaranteed once, sequencing, etc.).
Subscriber event registration – supports registry of event schema based on enterprise standards for subscribers and delivery QoS—guaranteed once, sequencing etc.).
Filter/Rule Engine – supports filtering requirements for event messages for subscribers.
Publisher/subscriber event service – supports publishing and subscribing events using standard HTTP protocol-based REST services.
Publisher/subscriber event adapter – supports different channels (JMS, MQ, DB, etc.) for publishers/subscribers (only In case the publisher/subscriber is not able to consume events using standard HTTP endpoints.
List event – supports listing of events (up to X months) by publishers.
Event registry – supports registering events (schema, publisher) from various publishers and event consumption from various subscribers.
Event catalog – supports an event catalog for subscribers to see the list of events they can consume.
Event Store – A real-time dynamic event store to persist and accurately register all events that pass through VMware Event Hub (including audit trail)
Event archive – supports event archival capability at regular intervals.
Replay event – supports event replay capability for subscribers.
VMware Event Hub dashboard – supports a central view, monitors all events and ensures reliability and accuracy of these events.
VMware Event Hub Features
VMware Event Hub login is enabled via VMware Workspace ONE®. It provides the capabilities shown in Figures 8 – 14.
VMware Event Hub was built using Opensource Kafka, reacts, VMware Tanzu® Kubernetes Grid™, VMware vRealize® Code Stream™ VMware VMware Aria Operations™ for Applications (formerly VMware Tanzu Observability by Wavefront).
The bottom line
Event-driven architecture is a powerful design pattern that enables systems to be highly scalable, flexible, and responsive to changes. By leveraging events as the primary means of communication between components, event-driven architecture allows for loose coupling and promotes modularity, making it suitable for building complex and distributed systems. It also requires careful consideration of event design, event handling, and error handling to ensure the reliability and correctness of the system. Proper planning, design, and implementation are key to successfully adopting event-driven architecture in a software system. Overall, event-driven architecture is a popular choice for building modern, reactive, and resilient software systems. So, when designing your next system, consider leveraging event-driven architecture for its benefits in scalability, flexibility, and responsiveness.
VMware on VMware blogs are written by IT subject matter experts sharing stories about our digital transformation using VMware products and services in a global production environment. To learn more about how VMware IT uses VMware products and technology to solve critical challenges, visit our microsite, read our blogs and IT Performance Annual Report and follow us on SoundCloud, Twitter and YouTube. All VMware trademarks and registered marks (including logos and icons) referenced in the document remain the property of VMware.
