Representing information as a sequence of events.
Rather than:
Day
Bank Balance
0
$10
1
$20
2
$15
3
$30
4
$20
It would be:
Day
Transaction
0
+10
1
+10
2
-5
3
+15
4
-10
The first ledger the data is represented by a
collection of states
the system has been in. The second a
list of events
, that is;
a list of changes that have been made
.
These are both equally simple, but the second stores more information than the first. Why is this? Because by knowing all the transactions, you can work out what the state of the system is at any given time. Knowing a list of states you cannot work out every single transaction (multiple transactions could have happened between states).
It is also the most honest way of representing data. Information about what happened is lost when only snapshots are stored, all of it is intact and preserved when stored as a sequence of events.
Not obvious from the example but snapshots can be big and mean a lot of unnecessary information is stored. In the example there is only one value (the bank balance) but in the real world there could be a lot of data.
Look at this:
Day
Bank Balance
0
$10
1
$10
2
$10
In this ledger we have three "states" or "snapshots" recorded which contain no useful information. With event sourcing, since there is no event here, nothing needs to be stored. We do not waste resources copying when nothing happens and storing data with no useful information. The lack of any transaction during days 0, 1 and 2 is enough to determine the bank balance on all three of these days (which will be whatever it was last).
With event sourcing
1.
Every fact of the matter is stored, everything that happened, it is the most honest way of representing data
2.
It is possible to derive every state of the system without storing a snapshot of what the system was like (very expensive)
Made with love and Elm Pages