Event-Driven Architecture (EDA) Pattern
An Event-Driven Architecture (EDA) Pattern is a communication-focused system architecture pattern that structures software systems around the production, detection, routing, and consumption of computing events through loosely coupled components.
- AKA: Event-Driven Architecture Pattern, EDA Pattern, Event-Based Architecture Pattern, Event-Oriented Architecture Pattern.
- Context:
- It can typically structure System Components into:
- Event Producers that generate event streams through event emitter mechanisms.
- Event Routers that manage event distribution via event channel infrastructure.
- Event Consumers that process events using event handler patterns.
- Event Processors that transform event data through event processing pipelines.
- It can typically support Event Processing Models such as:
- Simple Event Processing for immediate event reactions via direct event handlers.
- Complex Event Processing for pattern detection through event correlation engines.
- Event Stream Processing for continuous data transformation using real-time data streams.
- It can typically enable Architectural Benefits through:
- System Decoupling for reduced system dependency via asynchronous messaging patterns.
- Horizontal Scaling for improved system performance through distributed event processing.
- Dynamic Configuration for flexible system evolution using runtime event routing.
- Real-Time Responsiveness for immediate event-driven reactions through low-latency processing.
- It can typically implement Event Communication through:
- Pub/Sub Model for subscription-based distribution via topic-based routing.
- Event Streaming Model for log-based distribution through append-only logs.
- Message Queue for guaranteed delivery using persistent message stores.
- Event Bus for broadcast communication via centralized event routers.
- It can typically handle Event Types including:
- Triggering Events that initiate system actions through event-driven workflows.
- Notification Events that inform interested components via event broadcasts.
- State Change Events that represent system transitions through event sourcing.
- Command Events that request specific operations via event-driven commands.
- It can typically manage Event Lifecycle through:
- Event Creation by event sources using event factory patterns.
- Event Validation through schema enforcement via event contracts.
- Event Routing using content-based filters through routing rules.
- Event Processing by event handlers via async event handlers.
- Event Storage in event stores for event replay capability.
- ...
- It can often integrate with System Architectures through:
- It can often support Advanced Patterns including:
- Event Sourcing Pattern for state reconstruction from event history.
- CQRS Pattern for read-write separation through dual models.
- Saga Pattern for distributed transactions via compensating actions.
- Event Collaboration Pattern for choreographed workflows through event chains.
- It can often enable Quality Attributes such as:
- Fault Tolerance through event retry mechanisms and dead letter queues.
- Eventual Consistency via asynchronous propagation of state changes.
- Auditability through event logs providing complete history.
- Testability via event replay and event simulation.
- ...
- It can range from being a Simple Event System to being a Complex Event System, depending on its event processing requirements.
- It can range from being a Synchronous Event System to being a Asynchronous Event System, depending on its event delivery model.
- It can range from being a Centralized Event System to being a Distributed Event System, depending on its event routing topology.
- It can range from being a Stateless Event System to being a Stateful Event System, depending on its event processing context.
- It can range from being a Push-Based Event System to being a Pull-Based Event System, depending on its event consumption model.
- ...
- It can implement Design Patterns including:
- Reactor Design Pattern for handling concurrent service requests through event demultiplexing.
- Event Handler Pattern for processing individual events via handler methods.
- Event-Driven Programming Pattern for structuring application logic around event occurrences.
- Event-Oriented Software Design Pattern for organizing system behavior through event interactions.
- It can utilize Technical Components such as:
- Event Store for event persistence with temporal ordering.
- Event Schema Registry for event contract management through versioning.
- Event Gateway for protocol translation between different systems.
- Event Monitor for observability of event flow patterns.
- It can connect with API Architectures through:
- Asynchronous APIs for non-blocking communication via webhooks.
- Application Programming Interface (API)s for event endpoints through REST event streams.
- GraphQL Subscriptions for real-time event delivery via persistent connections.
- WebSocket APIs for bidirectional event channels through full-duplex communication.
- ...
- It can typically structure System Components into:
- Example(s):
- Enterprise Architecture Implementations, such as:
- Event-Driven Microservices Architecture (MSA) for distributed systems using service event meshes.
- Event-Driven SOA for service integration through enterprise service buses.
- Serverless Architecture for event-based computation via function triggers.
- Event-Driven Enterprise Integration for system interoperability through integration event hubs.
- Event Processing Systems, such as:
- Stream Processing Platforms like Apache Kafka for high-throughput event streaming.
- Enterprise Service Bus for message routing through mediation flows.
- IoT Event Platforms for device data via edge event processing.
- Real-Time Analytics Platforms for event stream analytics through windowed computations.
- Event Pattern Implementations, such as:
- Event Sourcing for state management through event replay.
- CQRS Pattern for data consistency via command-query separation.
- Saga Pattern for distributed transactions through compensation logic.
- Event Choreography for decentralized workflows via event correlation.
- Domain-Specific Implementations, such as:
- Financial Event Architectures for trading systems processing market events.
- Healthcare Event Architectures for patient monitoring through medical device events.
- E-commerce Event Architectures for order processing via transaction events.
- Gaming Event Architectures for multiplayer interactions through game state events.
- Cloud Platform Implementations, such as:
- Development Framework Implementations, such as:
- Node.js Event Loop for asynchronous execution through callback queues.
- Spring Cloud Stream for microservice events via binder abstractions.
- AutoGen Framework implementing agent communication through event-driven messages.
- MediaWiki Event Management System for wiki change events through event bus infrastructure.
- AI System Implementations, such as:
- Event-Driven AI Systems processing AI event streams for intelligent automation.
- AI Development Workflow Automation using event triggers for pipeline orchestration.
- Event-Driven Agent Architectures enabling autonomous behavior through event perception.
- Ambient AI Agent systems monitoring continuous event streams for proactive actions.
- ...
- Enterprise Architecture Implementations, such as:
- Counter-Example(s):
- Request-Response Architecture, which uses synchronous communication with direct coupling.
- Batch Processing Architecture, which processes grouped data at scheduled intervals.
- ETL Architecture, which focuses on data transformation through extract-transform-load pipelines.
- Monolithic Architecture, which uses direct method calls within single deployment unit.
- Client-Server Architecture, which employs synchronous requests with tight coupling.
- See: Message-Oriented Middleware, Service-Oriented Architecture, Architectural Pattern, Loose Coupling, Service (Systems Architecture), Serverless Computing, Event-Driven SOA, Asynchronous Messaging Pattern, Event Stream Processing, Computing Event, Reactor Design Pattern, Software System Component, Integration Platform, Real-Time Data Stream.
References
2023
- Bing Chat
- An event-driven architecture is an architectural style that allows systems to detect, process, manage, and react to real-time events as they happen. Events are changes in state or updates that occur in the system or the environment, such as a user action, a sensor reading, a message, or a timer. Events can either carry the state (the item purchased, its price, and a delivery address) or events can be identifiers (a notification that an order was shipped).
- An event-driven architecture consists of three key components: event producers, event routers, and event consumers . Event producers are the sources of events, such as devices, applications, or services. Event routers are the intermediaries that receive, filter, and distribute the events to the appropriate destinations. Event consumers are the sinks of events, such as functions, applications, or services, that perform some action or logic based on the events. Event producers and consumers are decoupled from each other, which means they do not need to know each other's identity, location, or implementation details. They only need to agree on a common event format and a topic or channel to publish and subscribe to .
- Some of the benefits of using an event-driven architecture are :
- It decouples the systems and reduces the complexity and dependency of the system.
- It improves the scalability and performance of the system by allowing parallel and asynchronous processing of events.
- It supports dynamic and flexible system configuration by allowing systems to join or leave the system at any time.
- It enables event-driven and reactive programming models that can handle complex and unpredictable scenarios.
- Some of the challenges of using an event-driven architecture are :
- It may introduce latency and unreliability in the event delivery due to network failures or router congestion.
- It may cause event duplication or loss if the router does not provide guaranteed delivery or ordering of events.
- It may require additional security and privacy mechanisms to protect the events from unauthorized access or modification.
- It may increase the testing and debugging difficulty due to the lack of visibility and control over the event flow.
2021
- (Wikipedia, 2021) ⇒ https://en.wikipedia.org/wiki/Event-driven_architecture Retrieved:2021-11-27.
- Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events.
An event can be defined as "a significant change in state". [1] For example, when a consumer purchases a car, the car's state changes from "for sale" to "sold". A car dealer's system architecture may treat this state change as an event whose occurrence can be made known to other applications within the architecture. From a formal perspective, what is produced, published, propagated, detected or consumed is a (typically asynchronous) message called the event notification, and not the event itself, which is the state change that triggered the message emission. Events do not travel, they just occur. However, the term event is often used metonymically to denote the notification message itself, which may lead to some confusion. This is due to Event-Driven architectures often being designed atop message-driven architectures, where such communication pattern requires one of the inputs to be text-only, the message, to differentiate how each communication should be handled. This architectural pattern may be applied by the design and implementation of applications and systems that transmit events among loosely coupled software components and services. An event-driven system typically consists of event emitters (or agents), event consumers (or sinks), and event channels. Emitters have the responsibility to detect, gather, and transfer events. An Event Emitter does not know the consumers of the event, it does not even know if a consumer exists, and in case it exists, it does not know how the event is used or further processed. Sinks have the responsibility of applying a reaction as soon as an event is presented. The reaction might or might not be completely provided by the sink itself. For instance, the sink might just have the responsibility to filter, transform and forward the event to another component or it might provide a self-contained reaction to such event. Event channels are conduits in which events are transmitted from event emitters to event consumers. The knowledge of the correct distribution of events is exclusively present within the event channel. The physical implementation of event channels can be based on traditional components such as message-oriented middleware or point-to-point communication which might require a more appropriate . Building systems around an event-driven architecture simplifies horizontal scalability in distributed computing models and makes them more resilient to failure. This is because application state can be copied across multiple parallel snapshots for high-availability.[2] New events can be initiated anywhere, but more importantly propagate across the network of data stores updating each as they arrive. Adding extra nodes becomes trivial as well: you can simply take a copy of the application state, feed it a stream of events and run with it. [3] Event-driven architecture can complement service-oriented architecture (SOA) because services can be activated by triggers fired on incoming events.
This paradigm is particularly useful whenever the sink does not provide any .
SOA 2.0 evolves the implications SOA and EDA architectures provide to a richer, more robust level by leveraging previously unknown causal relationships to form a new event pattern. This new business intelligence pattern triggers further autonomous human or automated processing that adds exponential value to the enterprise by injecting value-added information into the recognized pattern which could not have been achieved previously.
- Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events.
- ↑ K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
- ↑ Martin Fowler, Event Sourcing, December, 2005
- ↑ Martin Fowler, Parallel Model, December, 2005
2019
- https://softobiz.com/understanding-the-event-driven-architecture/
- QUOTE: ... Event-driven architecture. This software architecture paradigm promotes the production, detection, consumption of, and reaction to events. The event-driven architecture is a design pattern in which application data is defined as a stream of events. This streaming of data uses various mechanisms like message queues, enterprise service bus (ESB), most recent being Apache Kafka. ...
- QUOTE: ... Event-driven architecture. This software architecture paradigm promotes the production, detection, consumption of, and reaction to events. The event-driven architecture is a design pattern in which application data is defined as a stream of events. This streaming of data uses various mechanisms like message queues, enterprise service bus (ESB), most recent being Apache Kafka. ...
2018
- https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
- QUOTE: ... An event driven architecture can use a pub/sub model or an event stream model.
- Pub/sub: The messaging infrastructure keeps track of subscriptions. When an event is published, it sends the event to each subscriber. After an event is received, it cannot be replayed, and new subscribers do not see the event.
- Event streaming: Events are written to a log. Events are strictly ordered (within a partition) and durable. Clients don't subscribe to the stream, instead a client can read from any part of the stream. The client is responsible for advancing its position in the stream. That means a client can join at any time, and can replay events.
- On the consumer side, there are some common variations:
- Simple event processing. An event immediately triggers an action in the consumer. For example, you could use Azure Functions with a Service Bus trigger, so that a function executes whenever a message is published to a Service Bus topic.
- Complex event processing. A consumer processes a series of events, looking for patterns in the event data, using a technology such as Azure Stream Analytics or Apache Storm. For example, you could aggregate readings from an embedded device over a time window, and generate a notification if the moving average crosses a certain threshold.
- Event stream processing. Use a data streaming platform, such as Azure IoT Hub or Apache Kafka, as a pipeline to ingest events and feed them to stream processors. The stream processors act to process or transform the stream. There may be multiple stream processors for different subsystems of the application. This approach is a good fit for IoT workloads.
- QUOTE: ... An event driven architecture can use a pub/sub model or an event stream model.