Consistent ledger / Design note (conceptual)
A ledger that can always explain itself
Balances derived from mutable rows drift and cannot be audited. A double-entry ledger treats every movement as an immutable pair of entries, so any balance can be recomputed and any discrepancy traced to a posting.
- 01Transfer request
- 02Journal entry
- 03Balanced postings
- 04Balance projection
01 Model movements, not balances
A journal entry holds two or more postings that sum to zero per currency. Accounts are typed as asset, liability, or revenue so sign conventions are explicit rather than implied by the caller.
02 Enforce the invariant in the database
Postings insert only inside the entry transaction, and a constraint or trigger rejects an unbalanced entry. Nothing updates or deletes a posting; corrections are new reversing entries so history stays intact.
03 Reliability: derive balances, then cache them
The authoritative balance is the sum of postings. A maintained running balance per account makes reads cheap, and a scheduled job recomputes from the journal to prove the cache still agrees.
04 Scale: partition by account, batch by entry
Hot accounts serialise on row locks, so high-volume accounts split into sub-accounts that aggregate, or move to append-only postings with asynchronous aggregation. Contention, not storage, is the limit.
05 Trade-off: writes get slower and larger
Immutability costs storage and makes every movement at least two rows. In exchange, an auditor can be handed a query rather than an explanation.