Event Sourcing

Event sourcing captures every change to application state as a sequence of events, rather than updating an aggregate’s state in place. Martin Fowler’s statement of it is “capture all changes to an application state as a sequence of events”.

The events are the record of truth. Current state is a derived value, obtained by replaying an aggregate’s events from the beginning. Nothing is ever overwritten, so nothing is ever lost.

In a service designed around aggregates, this is implemented by having the service APIs that perform write actions publish business events, and having state derived from that stream.

What it enables

• Audit. The log of what happened is not a separate feature bolted on beside the data; it is the data. Every change carries its own cause and time.
• Temporal queries. State as of any past moment is recoverable by replaying up to that point, which makes “what did the system believe on the 4th?” an ordinary question rather than a forensic exercise.
• Recovery and rollback. A bad deployment that corrupted a projection is repaired by rebuilding the projection from the log, not by restoring a backup.
• System evolution. A new read model, a new report, a new downstream consumer can be built and then backfilled by replaying events that were recorded long before anybody wanted it.
• Debugging. A production defect can be reproduced by replaying the exact sequence that led to it.

What it costs

• Schema evolution never stops. Old events stay in the log forever in the shape they were written, so the code that replays them must keep understanding every version it has ever emitted. Versioning and upcasting are permanent work, not a migration.
• Replay cost grows. A long-lived aggregate accumulates events, and rebuilding it from the start eventually becomes too slow. Snapshots — a stored state at event n, replayed forward from there — are the standard answer and are additional machinery.
• Queries are indirect. Nothing can be answered by a query over current state unless a read model exists for it, which is why event sourcing and CQRS are so often introduced together.
• Deletion is hard. An append-only log is at odds with a right-to-erasure request. Plan for it — crypto-shredding, or keeping personal data out of the events and behind a key — before the first event is written, not after.

Because the log is immutable, a mistake is corrected by appending a compensating event, never by editing or removing the original.

Further reading

• Event Sourcing — Martin Fowler’s original write-up, with the replay and snapshot mechanics