EDA
How it works
An event producer publishes an event (typically an immutable record with payload and metadata) to a named channel (topic, queue, stream) on a broker. The broker durably stores the event and delivers it to registered consumers under one of two strategies: (1) pub/sub — every subscriber receives a copy of the event; (2) competing consumers — the event goes to exactly one consumer in a group, enabling load balancing. Consumers process events independently and may emit further events, forming a reactive flow graph. Related patterns include event notification (signal of change), event-carried state transfer (event carries full state), event sourcing (event log as source of truth), and CQRS (separating writes from reads).
Problem solved
Synchronous point-to-point RPC calls create tight temporal and topological coupling between services: each consumer must be available when the call is made, and the producer must know its consumers. Scalability, fault tolerance, and system evolution suffer. EDA removes these dependencies by introducing a mediator (event broker) and asynchronous communication.
Components
Component emitting events in response to a state change or user action.
Official
Mediator that durably stores and routes events (Kafka, RabbitMQ, NATS, Pulsar, EventBridge).
Official
Component subscribing to channels and reacting to events.
Official
Logical name of an event stream that producers publish to and consumers subscribe to.
Contract describing the event structure (Avro, Protobuf, JSON Schema, CloudEvents).
Official
Implementation
At-least-once delivery means event redelivery. Consumers must handle duplicates without side effects.
Asynchronous, distributed nature makes the causation chain hard to trace.
Changing an event schema can break older consumers.
Some operations require strong consistency; EDA introduces propagation delay.
An event that crashes the consumer blocks processing of subsequent events in the partition.
Evolution
Formalization of the pub/sub pattern in distributed systems (ISIS Toolkit, Cornell).
Hohpe and Woolf publish the catalog of message-based integration patterns — the enterprise EDA foundation.
LinkedIn open-sources Kafka — a log-based broker defining modern EDA.
Manifesto defining reactive systems (responsive, resilient, elastic, message-driven) — popularizing message-driven as a scalability foundation.
CNCF standardizes a vendor-neutral event description format.
Agent frameworks (LangGraph, AutoGen, CrewAI) adopt event-driven orchestration for multi-agent workflows and streaming inference.
Hyperparameters (configurable axes)
At-most-once / at-least-once / exactly-once. Affects consumer idempotency and operational cost.
Global ordering vs. per-partition vs. none. Trade-off between ordering and parallelism.
Time/size retention of events. Log-based brokers (Kafka) retain long-term, queue-based delete on ACK.
Partition key determines load balancing and ordering.
Compatibility strategy (backward / forward / full) for event schema evolution.
Execution paradigm
Execution is triggered by event arrival (reactive), not by a schedule or synchronous call.
The broker routes events to consumers based on topic name, partition keys, filters, or payload content.
Parallelism
Consumers scale horizontally via competing consumers / consumer groups. Stream partitioning (e.g. Kafka partitions) constrains parallelism within a partition key.
Hardware requirements
EDA is a hardware-agnostic architectural pattern — runs on CPU, cloud, and edge.