Event-Driven Architecture (EDA) Pattern

From GM-RKB
(Redirected from EDA Pattern)
Jump to navigation Jump to search

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.

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.

  1. ↑ K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
  2. ↑ Martin Fowler, Event Sourcing, December, 2005
  3. ↑ Martin Fowler, Parallel Model, December, 2005

2019

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.
Retrieved from "http://www.gabormelli.com/RKB/index.php?title=Event-Driven_Architecture_(EDA)_Pattern&oldid=927499"