Event-driven architecture

Pattern · Chapter 7

What it is

An event is the occurrence of something significant (e.g. a state change) that may interest other components or applications — e.g. a purchase order placed, a grade posted.
EDA is a distributed, asynchronous pattern that integrates applications/components through producing and handling events. Tracking events means nothing significant in the domain is missed.
Loosely coupled: the event producer knows nothing about subscribers or what actions result.
Complements SOA — service operations can be triggered by events, and services can raise events.
Trade-off: async + distributed processing brings complexity (responsiveness, performance, mediator/broker failures).

Event messages carry data about an event, created by producers, and travel over event channels (streams of messages) to an event processor.
Two implementations:
- Message queues → point-to-point channel pattern: guarantees exactly one receiver/processor per message; the channel handles contention, so processors need no coordination.
- Message topics → publish-subscribe (pub/sub) pattern: a publisher broadcasts to interested subscribers with no knowledge of who (or whether any) subscribes.

A single event queue plus an event mediator that routes/orchestrates events to processors.
Producers → event queue → mediator; mediator creates one or more async processing events sent to channels (queues or topics). Topics common here due to orchestration.
Used when processing an event takes multiple steps.
Mediator implementations by complexity: integration hub (simple, DSL routing rules) → BPEL engine (XML-based, complex orchestration, common with SOA/web services) → business process manager / BPM (models, automates, executes workflows; may use BPMN graphical notation, akin to UML activity diagrams; can include human interaction).

Event messages enter an event broker / event bus holding all channels (queues, topics, or both). No central event queue.
Processors pick events off the broker; processing may create new events fed back to the broker (event chaining).
Ideal when flow is simple and no centralized orchestration is needed.

Simple event processing (SEP): notable events immediately routed to a downstream action; real-time; also does schema transforms, event fan-out, payload enrichment.
Event stream processing (ESP): analyze streams, screen by conditions, act or ignore; real-time with decisions (e.g. stock-trading buy/sell on ticker changes).
Complex event processing (CEP): find patterns across events to detect a complex event (summarizes/represents a set of others), correlated causally/temporally/spatially; over longer windows (e.g. credit-card fraud detection). A system may combine all three.

Event notification (most common): system sends a message when an event occurs. Loose coupling between producer/consumer and between sending and responding logic. Drawback: hard to see the logical flow → harder to debug/maintain; often only monitoring reveals the flow.
Event-carried state transfer: a variant where the event carries enough state so consumers need not call back to the producer. Reduces network load; increases availability and resilience (consumer works even if producer is down) — but lowers consistency due to data replication.
Event-sourcing: persist all events (state changes) in an event store that becomes the source of truth; replay events to recreate application state (like a DB transaction log). Events must be immutable; corrections use compensating events. Benefits: debugging (replay) and detailed auditing. Costs: added complexity — must ensure correct event ordering across instances/threads, handle schema evolution of old events, and store external-system responses so replays don’t re-call them.

Software Architect’s Handbook (Packt, 2018), Ch.7 “Event-driven architecture”, pp. 516-536.