TRICKYwalkthrough
Double-Entry Ledger
In accounting, every transaction must have two sides: a debit and a credit. If a customer pays 50, credit merchant_revenue $50.
This is the double-entry principle, and it is how we guarantee that every cent is accounted for. Our ledger_entries table is append-only: we never update or delete a row.
“The sum of all debits must equal the sum of all credits at all times.”
A refund does not reverse the original entry; it creates two new entries: debit merchant_revenue 50. This makes the ledger a complete, immutable audit trail.
Why append-only? Because mutable records create reconciliation nightmares.
If someone edits a ledger entry, the audit trail is broken. Append-only means every historical state is recoverable by replaying entries from the beginning.
At 432M transactions/day with 2 ledger entries each, we write 864M ledger rows/day. Each row is ~200 bytes: entry_id (8B) + transaction_id (16B) + entry_type (4B) + debit_account (32B) + credit_account (32B) + amount_cents (8B) + balance_after_cents (8B) + created_at (8B) + metadata (84B).
Daily ledger storage: . Trade-off: double the write volume compared to single-entry, but the ability to reconcile to the penny is non-negotiable for financial systems.
Related concepts