olivlawolivlaw

From books

Lesson 10 · Accountants don't use erasers: record facts, derive states, recompute when you were wrong.

Pat Helland · Immutability Changes Everything · 2015 · Immutability Changes Everything, CIDR 2015 — rezumat (secțiunea 2 se numește „Accountants Don't Use Erasers”)2 minutes read
“There is an inexorable trend towards storing and sending immutable data. We need immutability to coordinate at a distance and we can afford immutability, as storage gets cheaper.”Pat Helland · Immutability Changes Everything · 2015 · Immutability Changes Everything, CIDR 2015 — rezumat (secțiunea 2 se numește „Accountants Don't Use Erasers”)

A correction is a new row, not an eraser.

An accountant does not erase a wrong entry; they add a correcting one. The ledger stays complete, anyone can redo the arithmetic, and "the balance" is a derived value, not a fact. Helland shows that modern computing is moving the same way: transaction logs, event logs, Parquet files written once, even SSDs that do not overwrite in place. When data is immutable, whole classes of problems vanish — lost updates, inconsistent reads, "who changed this?" — and two precious things appear: audit is free and any state can be recomputed. In a data warehouse, facts are naturally immutable: a sale happened. Corrections become new rows with the opposite sign or with a validity period, and late-arriving facts are appended, not "patched" into the past. Dimensions keep their history through versions — the next lesson. The only real conflict is with the GDPR right to erasure, for which there is an answer compatible with immutability, in lesson 19.

Passage 1: Think of a bank statement. The bank doesn't hand you a balance you must take on faith; it hands you the list of movements, and the balance is just their sum. You can dispute a line, not a conclusion. That's the twist Helland proposes: stop asking "what value is correct now?" and start asking "what events happened?". The value becomes an outcome, not a decision. This also changes how you build software: you stop writing code that scatters updates across ten tables, and start writing code that reacts to events and recomputes. Mistakes stop being disasters patched in secret and become new, visible events. And once everything is visible, a harder question appears: what do you do with facts that can never change, yet the law says you must be able to erase?

Why it matters A warehouse corrected in place cannot answer "what did the report show last month, and why". An append-only one always can.

RecordfactsDerivethe stateRecomputewhen
The facts never change; only the derivation is rerun.
Open on YouTube ↗

← Back to the feed