Why Ledgers Must be Immutable

Ledgers are a “get your shit together” tool.

The goal isn’t to record account balances, or where money comes and goes. A ledger’s purpose is to make the company trustworthy. All the strictness and the weird complexity isn’t to make life harder for engineers, or to prevent software bugs, but to keep accountants and auditors happy.

If a ledger can’t be trusted, neither can the company.

In order to interact with your ledger, all the other services have to make sure that they’re sending the right data in the right way. Sure, you can create a translation layer between the other services and the ledger, but that defeats its purpose: a service that initiates, validates, or completes money movements must be, implicitly, as strict as the ledger.

And the way that strictness is enforced is with a ledger that tolerates no bullshit through its interfaces.

All the strictness and complexity isn’t there to slow you down. It’s to create consistency, traceability, and proof.

• Proof that every money movement is intentional

• Proof that nothing can quietly disappear

• Proof that what the company says in aggregate matches the collection of what every transaction whispers individually

A ledger is discipline encoded in software.

This week, we’re looking at the most fundamental building block of ledgers: immutability. In most engineers’ mind, it translates to “append-only”. And sure, append-only databases are immutable because you can’t UPDATE or DELETE rows on them.

But that’s only the beginning of what immutability means for a ledger.

Here’s what you can expect in today’s article:

• A practical definition of immutability for ledgers (and why you can have it with mutable databases)

• The difference between Journaling and Posting ledger entries, and why it matters

• Why git is a nice metaphor for what a ledger’s immutability is about

• And for the database nerds, read skews, and why are relevant

Enough intro, let’s dive in.