Event sourcing, explained for people who run operations

Your accountant already works this way. A ledger is not a list of balances. It is a list of entries, each dated, each left alone once it is written. When an entry is wrong, nobody rubs it out. A second entry reverses it, and both stay in the book. The balance is not stored anywhere. It is worked out from the entries, and anyone who doubts it can work it out again.

Event sourcing is that idea applied to the rest of the operation. The name comes from software engineering, and most explanations of it are written for developers. This one is for the person who runs the plant, the warehouse or the desk.

State and history

Most business software stores state: what is true now. One row per thing, one value per field. Stock of an item: 412. Status of an order: approved. Net weight of a load: 23,450 kg. When something changes, the software writes the new value over the old one.

That is a sensible design. It is quick to read, and for many things the present is all you need. Its limit is that the present is all it has. If the net weight was a different figure this morning, the field does not know. Who changed it, and why, was never part of the field.

An event-sourced system stores history instead. It keeps a list of what happened, in order: the truck arrived, it was weighed in, it was unloaded, it was weighed out, the net weight was worked out, the net weight was corrected. Each line has a time and a person. Nothing on the list is ever edited or removed. The current net weight is whatever the list adds up to.

The two designs can show you the same screen. The difference is in what each can answer.

Question	A system that stores state	A system that stores events
What is the figure now?	Yes	Yes
What was it before?	Only if a separate log was kept	Yes: it is on the list
Who changed it, and when?	Only if a separate log was kept	Yes: it is on the event
Why does stock not match?	Someone investigates	Read the events for that item

An ordinary Tuesday

The value of this does not show in a demonstration. It shows in the questions that come up in a normal week.

A supplier disputes a deduction. They were paid less than the weighbridge slip suggests. A system that stores state shows the final amount. With events you see the reading that was taken, the rule it was checked against, the person who decided the deduction, and the time of each. The conversation is short because the record is complete.

Stock is out by a small amount. Where the system stores a closing balance, there is one number and it is wrong. Somebody counts, writes the new figure over it, and the cause is never found. Where stock is the sum of receipts, issues and adjustments, the difference sits in one of those events, and it can be found.

An approval is questioned. Someone says they approved a purchase at one rate and it went through at another. If approval is a status field, it says “approved”. If approval is an event, it says who approved, when, and what the figures were at that moment. A later change is a later event.

A mistake is corrected. Mistakes are normal. What matters is how the correction is stored. Written over the original, it is invisible, and an invisible correction cannot be told apart from tampering. Added as a new event, it is as visible as the original entry, with a name beside it.

Management asks a new question. Nobody thought to report on the time between gate entry and unloading. A system that stored only the current status cannot answer for last quarter. A system that stored each step, with its time, already holds the answer.

What it looks like in a real system

A multi-plant power producer buys biomass fuel from farmers, balers and aggregators. Every vehicle’s visit is a trip that passes checkpoints: gate entry, quality, gross weight, unloading, tare and exit. Each is recorded as an event, by the person whose job it is.

When a moisture reading falls outside the quality policy, the system raises a breach. An approver decides it and sets a deduction. That decision is not an edit to a price field. It is an event with a time and a name, sitting between the reading that caused it and the invoice that carries it. Anyone looking at the invoice later can walk back along the chain.

Stock is the same record read another way. A completed trip credits a stack. Feeding the belt takes from it. Stock is not a separate sheet that somebody has to keep in step: it is what the events add up to.

What it means for owning your systems

So far this has been about answering questions. There is a second reason to care, which matters more over several years than in any one week. A record built from events is a different kind of asset from a database of current values, and it changes what it means to own the software that runs your operation.

A history that cannot be quietly rewritten

In a system that stores state, whoever can reach the database can change a figure, and afterwards the figure looks as if it had always been so. That is true of a careless user, a helpful administrator and a vendor’s support engineer alike. You are trusting everyone with access, for ever.

In an event-sourced system the list is only ever added to. A figure cannot change without a new event, and the new event carries a name and a time. This holds for the people who built the system as much as for the people who use it. If you intend to own your record, and not merely be shown it, this is the property to ask about. A history that someone else can tidy is not fully yours.

It also matters on the day a system changes hands. A new team, whether a different supplier or your own engineers, inherits the whole account of what happened, and not just the closing balances with a promise that they are right.

New processes read the history you already have

The second consequence is less obvious. Because every step was stored with its time and its person, the history contains more than anyone has yet asked of it.

Take the power producer’s example. Suppose the plant later wants a report on how long vehicles wait between gate entry and unloading, by supplier. Nothing new needs to be captured. The gate entry and the unloading are already events on every trip the system has recorded. The report reads them.

Now suppose something larger, at any business with a record like this: a second system for a neighbouring process, such as planning purchases or maintaining the machines that handle the material. In a world of separate packaged products, that would be a new database, and the old data would be migrated into it, or keyed in again. On a shared record of events, the new process sits on the history that is already there. Trips, weights and deductions do not have to be moved or re-entered. They are read.

This is why a second system on the same foundation costs a fraction of the first, and why the first is worth doing carefully. An enterprise that owns an event history owns the raw material for systems it has not thought of yet.

One practical test follows. When a supplier shows you a new module, ask what it needs from the data you already hold. If the answer is a migration project, the two systems do not share a record.

What it does not do

Three cautions, so that the idea is not oversold.

It does not make a wrong entry right. If the operator types the wrong weight, the event records the wrong weight. What you gain is that the wrong figure and its correction are both on the record, each with a name.

It needs the events to be named properly. “Record updated” is not an event. “Tare weight recorded” is. Naming them means someone has to understand the operation step by step before anything is built. That is most of the work, and it cannot be skipped.

It makes corrections visible. This is the point, and it is also a change. People used to tidying a figure quietly will find that the tidy-up has their name on it. It is worth saying this out loud before a system goes live, so that a visible correction is understood as normal and not as an accusation.

Five questions to ask

If you are looking at any operational software, five requests will tell you which kind it is.

1. Change a figure in front of me. Now show me what it was before, who changed it and when.
2. Is that history kept for every kind of record, or only for some modules?
3. When stock, a balance or a status looks wrong, can I see the list of things that produced it?
4. Can anyone, including your own support staff, alter or remove an entry in that history?
5. If we add a new process or a new report next year, does it read the history we already have, or does it need the data moved?

A system built on events answers all five without anyone preparing for the question.

Phlo, the framework Jetbro builds on, works this way throughout. Every action is stored as an event, nothing is overwritten, and the current state is worked out from what happened. New processes sit on the history that is already there, without a migration. The reasoning is no newer than the ledger. An operation deserves the same kind of record its accounts have always had, and the enterprise that runs it should be the one that holds it.