Skip to content
Art2link ESB HomeDocumentationBlogContact
Updated May 5, 2026
Patterns/Advanced & future/Event sourcing

Event sourcing

Instead of storing only the latest state and losing how you got there, keep the events. The ordered stream of canonical events is the source of truth, and current state is simply what you get by replaying them in order.

An event-sourced view treats each change as an immutable canonical event, OrderPlaced, LineAdded, OrderShipped, appended to an event store. The bus is the distribution layer, not the log: it holds each event only until subscribers acknowledge it, so a dedicated send port must append every event to durable storage, such as a SQL table keyed by an ordering column. State is derived by folding the stored events together, and you can rebuild it at any time, or reconstruct what it was at any past point.

append-only event store (source of truth) OrderPlacede1 LineAddede2 LineAddede3 Shippede4 fold current state derived, rebuildable replay from the start to reconstruct state at any point in time

This builds directly on message-history & replay: where replay re-runs messages to recover, event sourcing makes that history the system of record. It pairs well with publish-subscribe, since any number of read models can each fold the same event stream into the shape they need.

Events are immutable facts. You never edit a past event, you append a new one that corrects it. Keep them named in the past tense and minimal, and they remain a faithful, replayable record.