Event-Driven Architecture & Event Sourcing

A single queue feeding a single worker pool is the simplest asynchronous pattern: one job, one place it gets processed. Event-driven architecture generalizes it. Instead of saying do this one task, a service announces that something happened, and any number of independent services can react, without the original service knowing or caring who is listening. This chapter explains that idea, and a related one that takes it to its logical end: storing the events themselves as the source of truth.

A letter says please bake a cake: it is addressed to one person, it is an instruction, and the sender has to know who can bake. A town crier announces a baby was born: it is about something that already happened, it is addressed to nobody in particular, and the crier does not know or need to know who is listening. The baker may start a cake, the florist may send flowers, and next year someone new can start listening without the crier changing a word.

• -The letter is a command: an instruction to a known receiver, which may succeed or fail.
• -The announcement is an event: a fact about the past, named in the past tense (OrderPlaced), which cannot be refused.
• -The listeners are subscribers, each reacting in its own way.
• -A new listener joining without the crier changing is the decoupling that makes event-driven systems easy to extend.

An Order service publishes one OrderPlaced event. Inventory reserves stock, Email sends a receipt, Analytics records a sale, and a new Fraud-check service can be added later by subscribing, with no change to the Order service at all.

A normal database stores the current state: this account has a balance of 120. Event sourcing stores every change instead, in an append-only log, and treats the current state as something you work out from it. Your bank statement is the everyday example: a list of deposits and withdrawals, from which the balance is derived. Here is the idea in a few lines, replaying four events:

Run it and read the last number on each line: 0, 100, 70, 120. Stopping after the third event shows the balance was 70 at that point, which is time travel for free. An append-only log of events has several useful properties:

• -A complete audit trail: you can see exactly what happened and in what order, which is valuable for money, medical and legal records.
• -Rebuildable views: a new report or search index can be built by replaying the whole history, even for questions nobody had thought of when the events were recorded.
• -Debugging: reproduce a bug by replaying the events that led to it.
• -Snapshots keep it fast: replaying millions of events for every read would be slow, so the system saves the state every so often (say every 1,000 events) and replays only the events after the latest snapshot.

• -Eventual consistency: subscribers react after the event is published, so other services see the change a moment later, not instantly.
• -Duplicates: delivery is usually at-least-once, so every subscriber must cope with seeing the same event twice.
• -Evolving events: an event written today must still be readable in five years, so changing its shape needs care.
• -Harder debugging: a single user action spreads across many services, so you need good tracing to follow it.
• -More machinery: for a simple application with one database, plain state is much easier. Use event sourcing where the history itself has value.

The Wiki card below goes further into event sourcing, including the read-model pattern that goes with it: