Databases use append-only database logs, also known as write-ahead logs, that only allow new data to be appended to the end of the log. Data can never be modified or deleted from the log. When a transaction is committed in an append-only database, the database will first write the transaction to the log. Once the transaction is written to the log, it is considered to be committed and cannot be rolled back. The database will then apply the transaction to the database itself.
Event sourcing follows a similar approach to append-only database logs. In event sourcing, all changes to the state of an application are recorded as a sequence of events. These events are then persisted in an append-only log called an event store. When the application needs to know the current state of an object, it replays all of the events in the event store for that object from the beginning. This process is called rehydration.
Event sourcing has several advantages over traditional database approaches, including:
Auditability: Event sourcing provides a complete audit trail of all changes to the state of the application. This can be useful for debugging problems or compliance purposes.
Reproducibility: Event sourcing makes it easy to reproduce the state of the application at any point in time. This can be useful for testing or disaster recovery purposes.
Scalability: Event sourcing is inherently scalable. This is because the event store can be easily partitioned and replicated
Projections are typically used to implement read models, which are read-optimized databases that store the current state of all objects in the application. Read models can be used to improve read performance, scalability, and flexibility. Different parts of an application often require specific views of the data. With event sourcing, you can generate and optimize projections to suit these specific use cases without affecting the primary event store. This flexibility allows for tailored views without compromising the integrity of the source data.