Event-Driven Architecture

A design pattern where components communicate by producing and consuming events — notifications that something has happened — rather than calling each other directly. Key properties: loose coupling, asynchronous, independently scalable.

"We moved from synchronous REST calls between services to EDA — the payment service emits a PaymentCompleted event and doesn't need to know about inventory, shipping, or loyalty points."

A record that something significant happened in the business domain. Named in the past tense. Events are facts — they cannot be rejected or undone.

"We emit an OrderShipped domain event when the warehouse confirms dispatch — downstream systems react to it independently."

A message that tells a service to do something. Named in the imperative: PlaceOrder, SendEmail. A command may be accepted or rejected — unlike events.

"PlaceOrder is a command — it can be rejected if the item is out of stock. OrderPlaced is a domain event — it records that the order was placed successfully."

A collaborative workshop technique where a cross-functional team maps out a business process using coloured sticky notes: orange (domain events), blue (commands), yellow (actors), purple (policies/business rules), green (external systems).

"Before writing any code, we ran a two-day event storming workshop — we discovered 30 domain events we hadn't considered and found where our bounded contexts should be."

A persistence pattern where the state of an entity is derived by replaying a sequence of events, rather than storing the current state directly. The event log is the source of truth.

"We use event sourcing for the order aggregate — we can reconstruct the exact state of any order at any point in time by replaying its event history."

A pattern that separates the write model (commands that change state, emit events) from the read model (queries that return state). Often combined with event sourcing.

"Our product catalogue uses CQRS — the write side handles inventory updates and emits events; the read side maintains a denormalised ElasticSearch index optimised for search."

A process that consumes events from the event store and builds a read model. Projections can be rebuilt by replaying all events from the beginning.

"Our analytics dashboard is a projection — it consumes all OrderPlaced events and builds aggregated sales statistics."

A pattern for managing long-running transactions across multiple services. Each step is a local transaction; each failure has a compensating transaction to undo it. Replaces distributed ACID transactions.

"Our order saga coordinates payment, inventory reservation, and shipment — each step can be compensated if a later step fails."

Two ways to implement a saga. Choreography: each service reacts to events autonomously — no central coordinator (loose coupling, harder to debug). Orchestration: a central orchestrator sends commands and waits for results (explicit control flow, single point of coupling).

"We chose orchestration over choreography because our order saga has 8 steps and conditional branches — the explicit orchestrator makes the flow understandable and testable."

The undo operation for a saga step — run when a later step in the saga fails. Each step must have a compensating transaction. Example: if ShipOrder fails after ChargePayment succeeded, the compensating transaction is RefundPayment.

"When the inventory reservation failed after the payment was charged, the saga ran the RefundPayment compensating transaction to restore consistency."

After a command is processed and an event is emitted, the read model will be updated eventually — not immediately. There is a brief window where write model and read model are out of sync.

"After a user updates their profile, the read model updates within 50–200ms — it's eventually consistent. We show the user their updated data immediately from the write model."

Where messages go when they cannot be processed — after repeated failures, poison messages, schema mismatches, or expired TTLs. Essential for diagnosing and recovering failed event processing.

"Failed events go to the dead letter queue — we monitor it daily and replay events once we've fixed the consumer bug."

A centralised repository for event schemas that stores the definition of every event type and enforces schema compatibility when events are produced or consumed.

"The schema registry rejected our producer update — the new schema was not backward compatible. We added the field as optional and it passed."

A consumer that can safely process the same message multiple times without duplicating side effects. Critical for at-least-once delivery systems.

"All our consumers are idempotent — we use the event ID as an idempotency key and skip events we've already processed."

A set of consumers that collectively consume a topic — each message in a partition is delivered to exactly one consumer in the group. Enables horizontal scaling of consumption.

"The orders topic has 50 partitions — our 50 consumer instances each own one partition, processing orders in parallel."