When it comes to building an application we can react on some events (for example a user clicked the SAVE button, then we send request to backend and it does the job) and then forget about them (events). Event Sourcing is a different approach – you store events (like SavedForm(clickedBy, datetime, …)) and also have logic reacting on these events – so to say business logic. In this post I would like to share a few basic ideas behind Event Sourcing.
Replay ability
As all events are stored, it is possible to replay events (run them against against your business logic).
Event Streams
To avoid storing all events in one place usually you go with Event Streams – so you strore events per some domain. So the replaying is faster.
Snapshots
When you need a really big Event Stream, then to have more performant replaying you can introduce snapshots (DB tables with current state).
No update/delete
In Event Sourcing there is no update/delete concept when it comes to events – current state is the result of all previous events.
How to query (for example all registered users)?
There is no events querying. If you need to query some data, then you need to introduce a read model (CQRS). So basically you introduce listeners on events which store data in a DB. So then it is possible to query a data from the DB.
You usually need a message distributor/relay
So to store and distribute events you need a distributor/relay like Kafka or NATS. The best is to have one which is consumer driver (consumer chooses what to listen to).
Analytics
Thanks to having all events it is easy to do some data analytics.