Software Architecture

Appearance

Chapter 15 — Event-Driven Architecture Style ​

Why This Chapter Exists ​

Request/response structures work well when workflows are predictable and tightly controlled. Many systems are not like that. As complexity grows—multiple consumers, parallel workflows, partial failures, and changing requirements—forcing everything into synchronous request chains increases coupling and fragility.

Event-driven architecture (EDA) is a different framing: systems react to things that already happened, through decoupled processing components connected by asynchronous communication.

What Event-Driven Architecture Is ​

Event-driven architecture is composed of decoupled event-processing components that asynchronously trigger and respond to events. It is less a technology choice and more a way of designing complex systems.

A request-based model asks the system to do something.
An event-based model announces that something has happened, and processors react.

Basic Topology ​

A common baseline topology includes:

  • Initiating event (something happened)
  • Event broker (topic/stream/notification channel)
  • Event processors (services/components reacting to events)
  • Derived events (new events emitted as outcomes)

Once an event processor hands off an event, it is no longer involved with that specific event and is free to react to other events.

Poison Events and Event Loops ​

A poison event occurs when derived events create a continuous triggering loop between processors (A triggers B triggers A…).

This is a practical risk in EDA because parallelism and decoupling make it easy to accidentally form cycles in event flows.

Events vs Messages ​

EDA discussions often require distinguishing “event” from “message.”

Event ​

  • indicates something has happened (“OrderPlaced”)
  • generally does not require a response
  • one-to-many (publish/subscribe)
  • sent via topics/streams/notification channels

Message ​

  • directs something to be done (“ApplyPayment”, “ComputeShippingOptions”)
  • usually expects processing by a specific receiver
  • one-to-one (point-to-point)
  • sent via queues/messaging services

Illustrative examples:

  • “Flight 6557, turn left heading 230°” → message
  • “A cold front has moved into the area” → event
  • “Turn to page 145” → message
  • “Sorry I’m late for the meeting” → event

The architectural relevance: events favor semantic decoupling (broadcast without knowing consumers). Messages favor directed intent and stronger coupling.

Swarm of Gnats Anti-Pattern ​

Event processors can trigger many derived events. If a processor emits too many fine-grained events, the system can devolve into a “swarm of gnats”:

  • excessive event volume
  • noisy event flows
  • difficult reasoning and governance
  • increased operational load

Granularity matters at two levels:

  • event granularity (too many events)
  • payload granularity (anemic vs rich payload)

An extensive derived event is one that currently has no consumers but still provides an extensibility hook.

Sync vs Async: Responsiveness vs Performance ​

EDA relies primarily on asynchronous communication:

  • fire-and-forget (no response expected)
  • request-reply messaging when an immediate response is required (pseudo-synchronous)

Asynchronous communication tends to increase responsiveness:

  • user is notified the action is accepted and will be processed

This differs from performance:

  • end-to-end completion speed

Async can improve perceived responsiveness even when total processing time remains the same.

Dynamic Quantum Entanglement ​

Synchronous communication between architectural quanta can cause dynamic quantum entanglement:

  • two quanta must block and wait on each other
  • they effectively behave as one quantum at runtime
  • architectural characteristics start to live “between” them

Replacing sync calls with async communication can detangle quanta by removing the dynamic dependency.

Semantic Decoupling: Broadcast Without Knowing Consumers ​

EDA allows broadcasting events without knowing:

  • which processors receive them
  • what processing they perform
  • whether any processor responds at all

This is a form of semantic decoupling:

  • processors depend on event meaning, not specific peer services

Event Payload Trade-offs ​

The information inside an event is its payload. Payload strategy is a core trade-off area.

Data-Based Payload ​

Event contains all information needed for processing downstream.

Benefits

  • fewer database queries
  • improved performance/scalability/responsiveness
  • more autonomy for consumers

Costs

  • higher stamp coupling (payload grows “just in case”)
  • harder contract management/versioning
  • harder data consistency when multiple systems store similar data

Key-Based Payload ​

Event contains only a key/identifier; consumers query data stores for context.

Benefits

  • simple, stable contracts
  • easier versioning/deprecation
  • lower bandwidth usage
  • better consistency (system of record remains centralized)

Costs

  • more database access (potential bottleneck)
  • lower performance/scalability (if DB is heavily shared)
  • risk of “anemic events” (not enough context for meaningful processing)

Table placeholder:

  • payload-tradeoffs-table.png — Data-based vs Key-based across criteria (performance, contract mgmt, bandwidth, DB access, fragility)

The recurring trade-off often simplifies to:

  • scalability/performance vs contract manageability/bandwidth

Anemic Events ​

An anemic event is a derived event whose payload lacks sufficient context for downstream decision-making or processing.

This is different from swarm-of-gnats:

  • anemic event = payload too thin
  • swarm of gnats = too many events (event granularity problem)

Controlling Event Workflow: Two Topologies ​

EDA is often implemented using one of two high-level topologies.

1) Broker Topology (Choreography) ​

  • no central mediator
  • processors publish events
  • other processors respond
  • workflows emerge as chains/trees of events

Strengths:

  • high scalability and performance
  • strong decoupling

Costs:

  • harder to reason about end-to-end flow
  • harder error handling and recoverability
  • harder “completion” determination (when is an initiating event truly done?)

2) Mediator Topology (Orchestration) ​

  • an event mediator manages/control workflow
  • mediator sends commands (often messages) to processors
  • processors typically do not broadcast actions; mediator coordinates

Strengths:

  • better workflow control
  • improved error handling, restartability, recoverability
  • clearer completion semantics

Costs:

  • mediator becomes a coordination point
  • performance/scalability lower than pure choreography

The trade-off often reduces to:

  • workflow control + error handling vs
  • performance + scalability

Preventing Data Loss and Handling Bad Events ​

EDA systems face unique failure modes:

  • events/messages dropped
  • consumer crashes mid-processing
  • out-of-sequence resubmission
  • replay and duplication concerns

Two commonly referenced mechanisms:

  • Producer: synchronous send + persistent queue
  • Consumer: client acknowledge mode
    (ack only after transaction/commit succeeds)

A workflow-style error handling pattern often appears:

  • consumer forwards bad event to a workflow processor
  • workflow processor attempts repair
  • repaired event is resubmitted to original queue
  • unrepairable events go to a dashboard for manual intervention

Request-Reply in EDA (Pseudo-Synchronous) ​

Sometimes a response is required quickly. EDA handles this through request-reply messaging.

Two common implementations:

  • Correlation ID (matching response to request)
  • Temporary queue for responses

Temporary queues are simpler conceptually but can burden brokers at high volume and concurrency.

Database Topologies in EDA ​

EDA may use several DB topology shapes:

Monolithic DB Topology ​

All processors share a central DB.

Benefits:

  • all data accessible centrally
  • processors query what they need without sync service calls

Costs:

  • central DB is a fault tolerance bottleneck
  • scaling DB becomes critical
  • schema changes require broad coordination (change control)

Domain DB Topology ​

Processors grouped by domain; each domain owns its DB.

Benefits:

  • better fault tolerance and scalability than monolithic DB
  • schema changes impact fewer processors
  • aligns with domain boundaries when they are stable

Costs:

  • more distributed data ownership
  • cross-domain queries become harder
  • sync communication pressure can reappear

If many processors require synchronous communication across domains, it may signal:

  • domain boundaries are misdrawn, or
  • the system is drifting away from a good EDA fit

Dedicated DB Topology ​

Each processor owns its DB.

Benefits:

  • highest fault tolerance and change control
  • DB scales per processor bounded context
  • schema changes isolated

Costs:

  • expensive operationally and cognitively
  • strongest pressure toward eventual consistency and distributed data semantics

Governance: Observability and Coupling Control ​

EDA is inherently dynamic and non-deterministic. That increases governance reliance on:

  • observability (logs, tracing, metrics)
  • contract management (static coupling via payload schemas)
  • monitoring sync calls (dynamic coupling)

Common governance concerns:

  • contract changes are risky because consumers may be unknown
  • stamp coupling: measuring unused fields in payloads across consumers
  • tracking synchronous communication between processors (and challenging its necessity)

EDA becomes harder to test and debug as event trees grow; hundreds or thousands of scenarios are plausible.

Team Topologies Fit ​

EDA’s decoupling can reduce day-to-day coordination, but the overall system complexity affects team fit.

General tendencies:

  • large, complex EDA reduces effectiveness of purely stream-aligned ownership
  • static contracts and derived-event semantics often require coordination across teams
  • complicated subsystem teams can own complex processors and infra concerns

EDA is often not considered strongly domain-partitioned in practice because a domain change can touch:

  • multiple processors
  • multiple topics/queues
  • multiple contract artifacts

Quanta in EDA ​

The number of architecture quanta varies:

  • can be many (independent processors with independent data)
  • can collapse via request-reply (pseudo-sync) which entangles processors into one quantum for that interaction

Even in a mostly async system, “response required now” interactions can pull quanta together.

Characteristic Profile (Qualitative) ​

Common strengths:

  • scalability and elasticity (via independent processor scaling)
  • fault tolerance (via async decoupling and eventual consistency patterns)
  • extensibility (new processors can subscribe and react)
  • responsiveness (fast acceptance + background processing)

Common costs:

  • low simplicity (non-deterministic flows)
  • hard debugging/testing (event trees explode)
  • difficult recoverability (depends on workflow/error strategy)
  • hard “done-ness” determination (when is processing complete?)
Architecture Style
Event-Driven
PARTITION TYPE
Technical
COST
NUMBER OF QUANTA
1
1 to many depending on db interactions
SIMPLICITY
complicated but powerful
MODULARITY
MAINTAINABILITY
TESTABILITY
nondeterministic, dynamic event flows
DEPLOYABILITY
EVOLVABILITY
very dynamic
RESPONSIVENESS
async communication w/ highly parallel processing
SCALABILITY
ELASTICITY
FAULT TOLERANCE
decoupled, async event processors

Event Model vs Request Model: Trade-offs ​

EDA often provides:

  • better adaptability and extensibility
  • better reaction to situational awareness
  • better real-time decision support
  • better responsiveness and parallelism

Trade-offs commonly include:

  • eventual consistency
  • less control over flow
  • debugging/testing difficulty
  • completion ambiguity

Table placeholder:

  • eda-vs-request-tradeoffs.png — advantages vs trade-offs

Frontend Context (React / Next.js Lens) ​

Frontend teams experience EDA indirectly:

  • via backend event workflows that create eventual consistency in UI
  • via “accepted, processing…” UX patterns
  • via websockets/SSE updates, notifications, streaming states
  • EDA makes “instant final state” less reliable:
  • UIs often need intermediate states and reconciliation
  • observability becomes a product concern, not just an ops concern
  • API contracts may represent “eventual truth” rather than immediate truth
  • EDA is powerful, but it pushes complexity into workflow reasoning, operational visibility, and contract evolution.

Closing Perspective ​

Event-driven architecture is one of the most powerful styles for complex, dynamic systems—because it embraces decoupling, parallelism, and asynchronous processing.

Its core trade is clear:

  • increased flexibility, scalability, and responsiveness in exchange for
  • reduced determinism, increased governance burden, and higher observability needs

Architectural work in EDA is less about defining perfect flows and more about managing trade-offs as workflows evolve.