Event Sourcing: A Foundation Guide

Why We Stopped Overwriting Our Own History

Every engineering team eventually runs into the same conversation. A customer or a support agent asks, “what was the status of this shipment three days ago, before it got marked as lost?” and the honest answer is: we don’t know, we overwrote it. That question is usually the moment Event Sourcing stops being an academic pattern in a conference talk and starts looking like a real option.

The Problem with Only Remembering “Now”

Most systems are built around CRUD: create a row, then update it in place whenever something changes. It works well until someone needs to know how the data got to its current state. A traditional shipments table might tell you a shipment is “dispatched,” but it can’t tell you it was delayed twice, reassigned to a different picker, and had one item swapped out after a stock discrepancy. Every update quietly erases the update before it.

That loss shows up as real pain: support teams can’t explain what happened, analytics teams can’t reconstruct historical trends, and debugging a production incident becomes guesswork because the evidence was overwritten hours ago. Event Sourcing exists to fix exactly this problem.

What Event Sourcing Actually Is

Event Sourcing is an architectural pattern where every state change is recorded as an immutable event, instead of updating a database row in place. Rather than storing “shipment status = dispatched,” you store the full sequence of facts that led there: ShipmentCreated, InventoryAllocated, PickingStarted, ItemPicked, Packed, Loaded, Dispatched. The current state isn’t stored directly at all - it’s reconstructed on demand by replaying those events in order.

This is a genuine shift in mindset. A CRUD system asks “what is true right now?” An event-sourced system asks “what happened, in what order, and what does that add up to?” The second question turns out to be far more useful for auditability, debugging, and analytics, because nothing is ever thrown away.

The Core Building Blocks

A handful of concepts show up in almost every event-sourced system. They fit together like this:

• Events represent facts that have already happened - ShipmentCreated, InventoryAllocated, and so on. They are immutable, always named in the past tense, and typically carry metadata such as a timestamp, user ID, correlation ID, and version number.
• Event Store is the source of truth. It’s an append-only store: events are written sequentially and are never updated or deleted. Events are grouped into streams, usually one stream per aggregate, and version numbers enforce optimistic concurrency so two conflicting writes can’t silently clobber each other.
• Aggregates are the consistency boundary that enforces business rules. An aggregate receives a command, validates it, and emits domain events. Instead of loading a row from a table, it’s rebuilt by replaying every event in its stream.
• Commands express intent - CreateShipment, DispatchShipment. A command is a request for something to happen; an event is the record of what actually happened once that request was validated. The distinction matters: a command can be rejected, an event cannot.
• Event Streams belong to a single aggregate. Shipment-101’s stream might contain ShipmentCreated, InventoryAllocated, PickingStarted, and ShipmentDispatched, in that exact order. Replaying the stream from the start rebuilds the aggregate’s current state.
• Snapshots exist because replaying thousands of events on every read gets expensive. A snapshot captures the aggregate’s state at a specific version, so only the events after that version need to be replayed. Snapshots are a performance optimization - they should never replace the event store itself.
• Projections consume events to build read models optimized for querying. A single event can update several projections at once: a shipments table, an inventory dashboard, a reporting database. Because they’re derived, projections can always be dropped and rebuilt from the event store.

Watching It Work: A Warehouse Example

It helps to see the pattern applied to something concrete. In a warehouse management system, a single shipment moving through the warehouse produces a clean, ordered stream of events:

ShipmentCreated → InventoryAllocated → PickingStarted → ItemPicked → Packed → Loaded → Dispatched

If the read database were lost tomorrow - a bad migration, a corrupted table, a botched deploy - none of that history is actually gone. It can be rebuilt in full by replaying these events straight from the event store. That single property is what makes teams fall in love with the pattern once they’ve been burned by a CRUD system that couldn’t answer “what happened?” after an incident.

The End-to-End Flow

Zooming out, a typical request moves through the system like this:

Client → Command → Aggregate → Domain Events → Event Store → Event Bus → Projections → Read Database → API

The event store remains the permanent system of record. Projections exist purely for fast, convenient querying - they can be as denormalized as you like, because they’re disposable and can always be regenerated from the events that produced them.

What You Gain

Teams don’t adopt Event Sourcing for its own sake - it earns its complexity through a specific set of benefits:

• A complete, tamper-evident audit history of everything that ever happened to a piece of data.
• Real replay and time-travel debugging - you can reconstruct exact state at any point in the past.
• Natural, low-friction integration with event-driven systems, since events are already the currency of the system.
• The freedom to build multiple, purpose-built read models from the same underlying history.
• Stronger business traceability, which matters enormously in domains like logistics, finance, and healthcare.

What It Costs You

None of that comes for free, and it’s worth being honest about the trade-offs before committing to the pattern:

• Projections are eventually consistent, so a read model can briefly lag behind the event store.
• Event schemas evolve, and versioning them cleanly is a real, ongoing design problem.
• Storage grows continuously, since nothing is ever deleted - archival strategy becomes a first-class concern.
• Snapshotting adds another moving part that has to be managed and kept correct.
• Long streams mean longer replay times if snapshots fall behind.
• Designing aggregate boundaries well is genuinely hard, and getting it wrong is expensive to unwind later.

Event Sourcing vs. CRUD vs. CQRS vs. EDA

These terms get tangled together often enough that it’s worth pulling them apart. Event Sourcing persists events as the source of truth; CRUD persists only the current state and discards everything before it. CQRS separates the read and write paths of a system, and is frequently paired with Event Sourcing, but the two are independent - you can use CQRS with a plain CRUD database. Event-Driven Architecture is about how services communicate with each other, while Event Sourcing is about how a single service persists its own business history. They overlap in practice, but they’re solving different problems.

Best Practices We’d Tell a Team Starting Out

• Treat events as immutable, always - once written, never edit or delete them.
• Version your event schemas from day one; you will need to evolve them.
• Keep individual events small and focused on a single fact.
• Attach metadata (timestamp, user, correlation ID, version) to every event.
• Invest real time in aggregate boundaries - this is the design decision that’s hardest to change later.
• Implement optimistic concurrency on every write to the event store.
• Build idempotent consumers, since events can be redelivered.
• Reach for snapshots only once replay time actually becomes a measurable problem - not before.

Where This Leaves Us

Event Sourcing isn’t a replacement for CRUD everywhere - plenty of data genuinely doesn’t need a full history, and the added complexity isn’t free. But for domains where the sequence of what happened matters as much as where things ended up - shipments, orders, payments, anything that gets audited or disputed - it turns “we don’t know, we overwrote it” into “here’s the exact sequence of events.”