The core tension
A balance is the sum of all postings for an account. You can compute it two ways, and the choice shapes both correctness and performance.
Strategy one recompute from history
You fold over every posting at read time. This is always correct because it derives the answer from the source of truth, but it gets slower as history grows.
Strategy two materialized running balance
You keep a current balance column and update it with each posting inside the same transaction. Reads are fast, but the cached value can drift if a bug skips an update.
Snapshot hybrid
Most systems combine both. You store periodic balance snapshots and sum only the postings since the last snapshot. This bounds the scan cost while keeping a recomputable source of truth.
Operational guidance
- Always update the materialized balance in the same atomic transaction as the posting.
- Run a periodic recompute job to detect drift between cached and derived balances.
- Choose snapshot frequency to bound the number of postings scanned per read.
Key idea
Materialize balances for speed but keep the postings as the source of truth so any balance can be reverified.