A customer writes to Tiffin support: "My order says cancelled, but the rider was already at my door. Who cancelled it?" The support agent opens the order. The row says status = 'cancelled'. That's all it says. Who cancelled it, when, and what the status was just before, are gone. Each UPDATE wrote over the last answer.
Most databases store where things ended up. That's usually fine. But some data is really a story, and the story matters more than the last page. In this lesson we'll look at a way of storing the story itself, called event sourcing, and at what it costs you.
State versus history
Here's how Tiffin's orders table records one order today:
| id | status | rider_id | total |
|---|---|---|---|
| 9812 | cancelled | 344 | 480 |
And here is the same order, stored as a list of things that happened to it:
#1 OrderPlaced 20:02:11 customer 77, restaurant 12, total 480
#2 OrderAccepted 20:03:40 by kitchen tablet
#3 RiderAssigned 20:09:02 rider 344
#4 OrderPickedUp 20:24:15 rider 344
#5 OrderCancelled 20:37:50 by customer app, reason "taking too long"
The first version tells you the order is cancelled. The second tells you the customer cancelled it themselves, 13 minutes after pickup. Support can answer the question in ten seconds.
Event sourcing means storing every change to your data as an event in an append-only log, and treating that log, not a table of current values, as the source of truth.
Your bank already works like this. Your balance is not a number someone edits. It is the sum of every deposit and withdrawal on your statement. If the balance looks wrong, you don't argue about the number. You go through the list.