In standard web development, databases often use CRUD (Create, Read, Update, Delete) patterns. If a user changes their email, the database overwrites the old email. In financial systems, overwriting data is a cardinal sin.
A Financial Events System relies on Event Sourcing. Instead of storing just the current state (e.g., "Balance: $50"), the system stores the sequence of events that led to that state (e.g., "Deposit $100", "Spend $20", "Refund $30"). The current balance is simply the derivative sum of all historical events. This architecture is non-negotiable for auditability and debugging complex financial flows.
The Immutable Log vs. The Snapshot
The Log (Source of Truth): An append-only stream of JSON blobs or Protobuf messages. Event: PAYMENT_INITIATED | Time: 10:00:01 | ID: 123 Event: PAYMENT_SETTLED | Time: 10:00:05 | ID: 123 The Snapshot (Read Model): To avoid summing 1 million events every time a user loads their dashboard, the system projects these events into a SQL table (The Ledger) for fast reading. If the SQL table is corrupted, it can be dropped and perfectly rebuilt by "Replaying" the Event Log from the beginning of time.
Time Travel and Auditing
Event sourcing allows for "Time Travel Debugging." Scenario: A customer claims their balance was incorrect last Tuesday. Solution: The Ops team can replay the state of the system exactly as it existed on Tuesday at 11:59 PM. You can prove exactly why the balance was what it was, trace it back to specific webhooks or user actions, and generate a precise audit trail for regulators.
