EDA (Event-Driven Architecture)

EDA

Event-Driven Architecture

1. Overview: EDA, an architecture that breaks synchronous dependencies between services and loosely couples them via events

    flowchart LR
    A["Synchronous calls:<br/>tight coupling, failure propagation,<br/>limited scalability"] --"Event-based<br/>asynchronous communication"--> B["Event publish/subscribe<br/>Producer, Broker, Consumer"] --"Loose coupling,<br/>independent scaling"--> C["Resilient, scalable<br/>distributed system"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: An architectural pattern in which system components interact by producing, publishing, subscribing to, and processing events. Instead of calling each other directly, services communicate through an event broker with asynchronous, loose coupling, achieving scalability and resilience.

Characteristics: (Service independence) Event producers don’t need to know their consumers, maximizing independence between services. (Elastic processing) Asynchronous processing enables elastic handling of traffic spikes through event buffering. (Standard MSA pattern) A standard pattern for inter-service communication in microservice environments, often combined with Saga, CQRS, and Event Sourcing.

2. EDA’s core structure

A. Event-driven communication structure

    flowchart LR
    subgraph PRO["Event Producers"]
        direction TB
        P1["Order service<br/>publishes OrderPlaced"]
        P2["Payment service<br/>publishes PaymentCompleted"]
    end

    subgraph BRK["Event Broker"]
        direction TB
        B1["Topic/queue management,<br/>event buffering"]
        B2["Routing/filtering,<br/>ordering guarantees"]
    end

    subgraph CON["Event Consumers"]
        direction TB
        C1["Inventory service<br/>deducts stock"]
        C2["Notification service<br/>sends email/push"]
        C3["Shipping service<br/>starts delivery"]
    end

    PRO --> BRK --> CON

    style PRO fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
    style BRK fill:#1E3A5F,stroke:#1E3A5F,color:#fff
    style CON fill:#E8F5E9,stroke:#388E3C,color:#1B5E20

Component	Role	Representative technology
Event Producer	Creates and publishes an event when a business event occurs	Spring ApplicationEvent, Kafka Producer
Event Broker	Receives, stores, routes, and delivers events	Apache Kafka, RabbitMQ, AWS EventBridge
Event Consumer	Subscribes to events of interest and executes business logic	Kafka Consumer, Spring @EventListener
Event Schema	Standardizes event structure and manages backward compatibility	Avro, JSON Schema, Protocol Buffers

Comparing event delivery styles

Style	Characteristics	Suitable use case
Simple Event	Notifies only the fact of a state change (minimal information)	Notifications, triggers
Event-Carried State Transfer	The event carries the changed state data	Data synchronization between services
Event Sourcing	Stores every state-change event in sequence	Audit logs, time travel

B. Event Sourcing and CQRS patterns

    flowchart TD
    subgraph CMD["Command Side (writes)"]
        direction LR
        C1["Command<br/>request to create an order"]
        C2["Aggregate<br/>applies business rules"]
        C3["Event Store<br/>persists events"]
        C1 --> C2 --> C3
    end

    subgraph QRY["Query Side (reads)"]
        direction LR
        Q1["Read Model<br/>view table for queries"]
        Q2["Query Handler<br/>handles queries"]
        Q1 --> Q2
    end

    C3 --"Publishes event,<br/>updates Read Model"--> Q1

    style CMD fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
    style QRY fill:#E8F5E9,stroke:#388E3C,color:#1B5E20

Event Sourcing vs. traditional state storage

Comparison	Event Sourcing	Traditional state storage
Storage approach	Accumulates state-change events in sequence	Overwrites current state (snapshot) with the latest value only
History tracking	Full change history can be replayed	History is hard to preserve or query
Audit	Built-in, complete audit trail	Requires a separate audit log table
Complexity	Requires event design and replay logic	Simple CRUD pattern

Core CQRS principles

Principle	Description	Benefit
Separate Command and Query	Separate models/stores for data changes (Command) and reads (Query)	Each can be optimized independently
Write Model	An Aggregate centered on business rules and invariants	Guarantees consistency and integrity
Read Model	A denormalized view table optimized for query performance	Fast reads without complex joins
Eventual consistency	Allows slight delay in Write → Read model synchronization	Achieves high scalability and availability

3. Expected benefits and practical application of EDA

Category	Key expected benefit	Practical application
Loose coupling	Changes or failures in one service don’t propagate to others	Convert inter-service communication in MSA from REST calls to events
Scalability	Scale throughput horizontally by increasing consumer count	Use Kafka Consumer Groups for parallel processing per partition
Audit & traceability	Event Sourcing preserves the full history of state changes	Meet audit-trail requirements in regulated domains like finance and healthcare
Real-time processing	Real-time analysis and response based on event streams	Implement real-time anomaly detection and alerting with Kafka Streams/Flink

SOA (Service-Oriented Architecture)Serverless Architecture