Event Sourcing

An event store only lets you add new records, never change or delete old ones. Instead of overwriting a row to reflect current state, it keeps every change as its own permanent entry, in order.

Old events are stored forever and get replayed to rebuild state. If you change what a field means without a plan, old events break the code that reads them. Upcasting is a small translator that turns an old-shaped event into the new shape before your code sees it, so replay still works.

A projection is a separate copy of your data, built by reading through the history of every change (events) and turning it into a simple, fast-to-search table - like building an index from a diary instead of re-reading the whole diary every time you need an answer.

The system starts with an empty/default state and applies each stored event for that aggregate, one by one, in the order they happened, updating the state a bit with each event. Doing this to rebuild state is called rehydration; the loop that folds each event into state is the fold/reduce pattern.

Event sourcing rebuilds an object's state by replaying every event that ever happened to it. If there are thousands of events, that replay gets slow. A snapshot is a saved copy of the state at some point, so you only replay events since then.

Events travel from the write side to the read side afterward, taking a little time. If you read right after writing, the read model may not have caught up yet, so you can briefly see stale data.

Each write says 'I'm adding this assuming the stream currently has N events.' If someone else already added an event in between, the store rejects the write instead of accepting it blindly, so the app can retry with fresh data.

Grouping by aggregate id keeps each entity's own history together and in order, so you can load just that one entity's events fast, and two different entities' writes never block or interleave with each other.

Adding a new optional field is usually safe because old readers can ignore it and new readers can default it. Renaming, removing, retyping, or changing the meaning of an existing field is dangerous because old events won't have the new shape and something will misread them.

It reads through the entire history of past events first, from the very beginning, building up the data step by step, and once it reaches the present, it switches to just listening for new events as they happen - like binge-watching a show to get caught up, then watching new episodes live.

There are two separate jobs: first, figure out if the command is allowed and what should happen (the 'decide' step, checking business rules against the current state you just rebuilt); second, once you know what happened, update the state to reflect the new event (the 'apply' step). Keeping them separate means the apply step never has to think about whether something is allowed - it just records it.

The code fetches the newest saved snapshot, turns it into an in-memory object, then asks the event store for only the events recorded after that snapshot's position, and applies those events one by one to bring the object fully up to date.

You can snapshot every N events (like every 500 changes), on a timer (like nightly), or when loading gets slow. Event-count triggers keep replay short and predictable; time-based triggers are simpler but can let busy aggregates drift far behind.

The projector can crash, fall behind, receive duplicates, or choke on a bad event. Fix these with durable checkpoints, lag monitoring, idempotent updates, and the ability to replay events to rebuild the table from scratch.

Within one entity's own history, events always arrive in the exact order they happened. But if you're watching many entities at once, events from different ones can arrive interleaved in almost any order relative to each other, so you can't assume a global timeline unless the store gives you one explicitly.

The projection hasn't caught up to the newest event yet, so the read is briefly stale - like refreshing a scoreboard a split second before it updates. Common fixes: make the client wait for the update, read the write directly instead of from the projection, or show a temporary version on screen immediately.

Normal rehydration always folds every event to reach 'now.' Debugging replay instead stops folding partway through - at a specific event, timestamp, or version - so you can see exactly what the state looked like at that moment, without touching the live system or writing anything back.

A saga listens for events, and each time something happens it decides the next command to send to the next aggregate. It's like a conductor reacting step by step, instead of one big all-or-nothing transaction across everything.

You fix the buggy code, wipe out the broken table, and replay every past event from the start through the corrected logic to rebuild it fresh - like erasing a wrong total and re-adding every receipt correctly this time.

Each write carries a unique ID. If the same ID shows up twice because of a retry, the store recognizes it already processed that exact write and just confirms success again instead of adding a second copy.

Upcasting translates old events every time they're read, keeping the original bytes forever. Copy-and-replace instead writes a whole new, corrected copy of the event stream once, then switches everyone to read from that new copy — more work up front, but no more translation cost on every future read.

A weak schema just serializes events as loosely-typed JSON with a version number and trusts application code to handle whatever shape shows up. A strong schema registry enforces a formal, checked schema for every event version up front, catching incompatible changes before they can even be written.

The handler must be safe to run twice on the same event without messing up the data - for example, setting a value directly instead of always adding to it - because most event systems can redeliver an event after a crash rather than guaranteeing it's processed exactly once.

You can't rewrite old events - they're an immutable historical record - so instead you add a translation step, often called upcasting, that transforms an old-shaped event into the new shape (e.g., filling in a default warehouseId) right before it's folded, so the apply function only ever has to deal with one, current shape.

You can keep snapshots in the same database as events, or in a different, faster store. Same-store is simpler and stays consistent; a separate store can be optimized for fast reads but risks getting out of sync. Either way, you tag snapshots with a format version so old ones can be safely ignored if the code changes.

An aggregate should be just big enough to enforce the rules that must be true at every single instant. Anything that can tolerate a short delay to become consistent should live in a separate aggregate, coordinated afterward by a saga.

Replaying every stream at once can overload the database and downstream services (a 'replay storm'), and if the fold function isn't perfectly deterministic or the rebuild runs against a moving live system, the rebuilt projection can end up subtly different from what you'd get in production. You avoid this by rebuilding into a separate copy, throttling the replay, and only swapping it in once it's verified to match.

If two things try to save or read a snapshot for the same object at the same time, you can end up with a snapshot that doesn't match reality. Fix this by always deriving snapshots from a confirmed, already-saved event position, and by checking that the snapshot's numbers actually line up before trusting it.

You never rewrite old events; they stay exactly as they were recorded. Instead you translate old events into the new shape on the fly when they're read, or version the event type, and any projector reading them handles both old and new shapes.