Why Financial Systems Use Event Sourcing Instead of CRUD

Traditional CRUD architectures only record the current state — what the data is — but not why it became that way. In finance, this is unacceptable: you must be able to explain every cent's journey from the initial state to the present.

Three Core Concepts: Command, Event, State

Event Sourcing models the system with three elements:

Command : A user instruction, e.g., "transfer $1 to a friend."

Event : The system's validated conclusion, written in past tense — "$1 deducted from account A" and "$1 credited to account B." Only valid commands become events.

State : The result after applying events — balances change from 100 to 99 and 200 to 201.

These form a closed loop: state changes, users issue new commands based on the new state, the system validates, produces events, and updates state. This mirrors a 5v5 game engine: player actions are commands, the engine validates and emits events (e.g., "hero moved to coordinates"), and all clients' screens (state) sync.

Key insight: commands can be rejected (insufficient funds), but once an event is created it must execute. This is the first guarantee of correctness.

Order Is Everything: Why FIFO Queues Are Mandatory

Two commands arriving in different orders produce different outcomes. Example: balance = $100. Command A: receive $100. Command B: send $200.

If A then B: intermediate balance $200, both succeed.

If B then A: first command fails for insufficient funds.

Therefore, all commands and events must go through a strict FIFO queue — no reordering, no cutting in line. An optimization merges the command and event queues: process a command, emit its events, then append both together as a single sequential write. This yields pure append-only I/O, maximizing throughput on both SSD and HDD. Each queue has a fixed-length index file to locate the Nth event by offset calculation.

Automata, Time Machine, and Snapshots: The Audit Trilogy

Events are executed by an automaton — a deterministic state machine that reads the event log like a tape head: read event, mutate state, repeat. The automaton must have zero randomness and zero external dependencies; otherwise the same event sequence could yield different results, breaking auditability.

This determinism enables a Time Machine : replay from the beginning to reconstruct the exact state at any historical moment, just like loading a game save.

Replaying millions of events is slow. The solution is snapshots : periodically persist the current state. Recovery then loads the latest snapshot and replays only subsequent events. Recovery time depends only on events since the snapshot, not total history length.

Finance has a natural snapshot cadence: the daily cut-over (day-end reconciliation). Monthly, quarterly, and annual checkpoints reuse the daily snapshots.

Together, these three pieces give finance complete auditability: you can trace every dollar step by step from genesis to now. Internet systems record "what"; financial systems record "why."

CQRS: Read/Write Separation for Query Performance

Event Sourcing solves write correctness, but querying by replaying all events is impractical. CQRS (Command Query Responsibility Segregation) separates concerns:

Write side : handles commands, validates, produces events, appends to the FIFO log.

Read side : multiple "read-model automata" that only consume event copies and apply them. One read model stays at the latest state for real-time queries; others can be pinned to daily snapshots for historical queries.

This pattern also appears in gaming: a live spectator view is a read-model automaton mirroring the players' game states in real time.

CQRS lets each side optimize independently: write side uses sequential append-only I/O to saturate disk bandwidth; read side uses query-optimized structures (B+ trees, document stores) for low-latency reads. The two sides sync asynchronously via the event stream, never blocking each other.

The Mathematical Essence in One Formula

Represent the automaton as a function f(state, event) → new_state. The entire system reduces to: S_n = f(S_{n-1}, e_n) Unrolling:

S_n = S_0 + e_1 + e_2 + ... + e_n = sum of all event effects

This is why Event Sourcing guarantees correctness: it is equivalent to a mathematically verifiable, step-by-step derivation. The automaton must be deterministic because mathematical functions have no randomness. Events must be ordered because function composition is generally non-commutative (add then subtract ≠ subtract then add). FIFO storage reflects the inherent linear sequence of events.

From a time perspective, state is the integral of all past events; each event is the derivative of state with respect to time. A financial system isn't just bookkeeping — it's solving a continuously verifiable mathematical problem.

Event Sourcing Correctness Template

For any system demanding extreme correctness, the template is:

All operations become commands; only after validation do they emit events.

Commands and events are stored in strict FIFO order; sequential writes ensure high performance.

An automaton executes events one by one with zero randomness and zero external dependencies.

Snapshots plus time-travel replay enable point-in-time recovery for audit compliance.

CQRS separates write (correctness) from read (performance).

This architecture isn't theoretical — it's forged by decades of real-world financial practice. Master it, and correctness becomes a solved problem.