Blog

Example, say you are in the business of keeping the name and email address of people you know. Simple enough, you have a database table of people and a linked table of their email addresses. You fill this up as you go, creating, updating and deleting the records as people move job, get married or whatever.

A few years go by, and what you have is a comprehensive list of people, you are able to contact them and all is good in the business.

But you have lost data.

You only have the current state, and your new idea needs to know how often a person changes job and gets a new email address and you don't have that data.

If you had thought of that first, then you could have stored a list of previous emails, but you didn't. Maybe you have a backup database you could restore?.

This is what Event Sourcing, is useful for.

Instead of storing records of people or email addresses specifically, you store the change.

So a PersonCreatedEvent, PersonUpdatedEvent or an EmailUpdatedEvent.

From these events you can build your database the same way you did before and have the same UI for your users. But now you have all the details of the change and you are able to gather that information too, build new insights and enable ideas you haven't had yet.

However,

• You still have to craft your Events well.
• You will have to ensure you have the ability to store lots of data, long term.
• You will have recovery strategies for failure and corruption too.

This is a simple overview of something I have been fascinated with for many years, and it's not new, it's a ledger, and it's been used in transaction based services like banking forever.

For a full illustration, maybe for more technically-minded people, have a look at the address book app I have linked at the bottom of the page. Open the developer tools and look at the IndexedDb created there.

address-book.antix.co.uk

This entry was posted on LinkedIn