EDA (Event Driven Architecture)

I'm considering writing an article on Event-Driven Architecture (EDA) because it's increasingly prevalent in modern applications. It's important to explore both its optimal use cases and scenarios where alternative architectures might be more suitable.

What is event-driven architecture (EDA)

Event-driven architecture (EDA) is a modern architecture pattern built from small, decoupled services that publish, consume, or route events.

An event represents a change in state, or an update. For example: an item placed in a shopping cart, a file uploaded to a storage system, or an order becoming ready to ship.

EDA promotes loose coupling between producer and consumer services. This makes it easier to scale, update, and independently deploy separate components of a system.

An event-driven approach makes it possible to assemble and orchestrate services that process data at different rates.

Example

In the following example, an order acceptance microservice interacts with a payment processing system via a queue.

In the example, the order acceptance service buffers high volumes of incoming orders in a queue. The slower payment processing service then handles these messages steadily, managing state transitions, retries, and errors. The workflow service orchestrates the payment steps based on the system state, generating events for Inventory, Fulfillment, and Accounting services.

Event-driven architectures (EDAs) can provide an effective way to meet the demands of highly scalable and highly available workloads. EDA also applies well to workloads with unpredictable or “spikey” traffic patterns.

Benefits of Event-Driven Architecture (EDA)

1. Independent Scaling and Failure: EDA allows services to scale and fail independently, enhancing application resiliency. Services can handle varying loads and failures without affecting the entire system.
2. Agility in Development: Developers can avoid writing custom code for polling and routing events, as event routers handle these tasks, improving developer productivity and reducing the need for coordination between services.
3. Extensibility: EDA allows easy integration of new features and functionalities without affecting existing microservices. Event producers and consumers operate independently, minimizing dependencies.
4. Reduced Complexity: By decomposing complex workflows into simple, decoupled services, EDA simplifies management and orchestration. Services communicate asynchronously through event messages, making it easier to handle different processing rates.
5. Cost Efficiency: Push-based event flows operate on demand, reducing the need for continuous polling, saving on network bandwidth, CPU utilization, and other resources.

When to use ?

1. Integration of heterogeneous systems
2. Cross-Region, cross-account data replication
3. Resource state monitoring and alerting
4. Fanout and parallel processing

When not to use ?

1. Variable latency

Unlike monolithic applications, which may process everything within the same memory space on a single device, event-driven applications communicate across networks.

Workloads that require consistent low-latency performance are not good candidates for EDA. Two examples are high-frequency trading applications in banks or sub-millisecond robotics automation in warehouses.

2. Transactions

Some workloads are not well suited for EDA due to the need for ACID properties. However, many workloads contain a combination of requirements that are eventually consistent (for example, total orders in the current hour) or strongly consistent (for example, current inventory). For those features needing strong data consistency. You can go with DynamoDB or relational DB for transactions.EDA is not suitable in such scenarios.

3. Interactive applications

In many cases, event-based applications are asynchronous.For interactive workloads, such as web and mobile applications, the end user usually expects to receive a return value or the current status of a transaction. For these workloads, there are several design patterns that can provide rich eventing back to the caller. However, these implementations in an event-driven architecture are more complex than using a traditional asynchronous return value.

EDA across different clouds

Here's a simplified comparison focusing on core Event-Driven Architecture (EDA) services across AWS, Azure, and GCP: