event-sourcing

Overview ¶

Example: event-sourcing

Stores the history of an aggregate as events, then builds a read model from that history with a projection.

The event store shares the engine and the transaction of the application, so the events and any other write commit together. The projection advances its checkpoint in the same transaction as the read model, so it can never record progress that it did not make.

Key concepts shown:

• Append: events are written at expectedVersion+1 and up.
• Optimistic concurrency: a stale expected version returns ErrConcurrency.
• Read: rebuild one aggregate from its own stream.
• ReadAll + checkpoints: a projection walks the log in batches and resumes exactly where it stopped.
• Failure: a handler that fails leaves the checkpoint where it was.
• Reset: clear the read model and the checkpoint to replay the history.

The read of the whole log stops at a transaction watermark on Postgres, so a transaction that commits late can never slip behind the reader. SQLite serialises writers, so the insert order is already the commit order.

Runs against in-memory SQLite. No external database is needed.

Usage:

go run ./examples/event-sourcing/