Event Sourcing diagram template

Builds a new scene in your browser. Your existing scenes are not touched.

About this design

Event sourcing stores what happened instead of what is. Rather than overwriting a row with the latest balance, the system appends events such as deposited or withdrawn to an immutable log, and current state is whatever you get by replaying them. This gives a perfect audit trail, makes it possible to answer questions about the past and allows new read models to be built from history. An aggregate loads its events, applies a command, and appends new events; snapshots speed up aggregates with long histories. Projections consume the log to build query tables. This template shows the write path, the event store and two projections. Discuss versioning events that live forever, the difficulty of correcting mistakes, privacy deletion in an append-only log, and whether the benefits outweigh the extra thinking your team will need.

Diagram as text

This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.

title "Event sourcing"
direction LR
client "Client" -> service cmd "Command handler" -> db postgres "Event store"
event-store -> topic kafka "Event stream"
event-stream -> worker p1 "Balance projection" -> db postgres "Balances view"
event-stream -> worker p2 "Audit projection" -> search elasticsearch "Audit index"
cmd -> storage s3 "Snapshots"