The tension
A scalable payment system often computes a balance by aggregating asynchronous ledger events. Right after a charge, a read of the balance may not yet reflect it. The balance is eventually consistent: it converges once all events are applied.
Why allow lag
- Forcing every read to be strongly consistent adds latency and coordination.
- Spreading work across replicas and async pipelines improves throughput and availability.
Designing for it
- Keep an authoritative ledger that is the true source, and treat derived balances as projections.
- Use a monotonic version or sequence so a client never sees the balance move backward.
- For decisions that must not overspend, check against a strongly consistent reserved balance, not the lagging projection.
The honest line
- Show users the projection for display, but guard money moving actions with the authoritative state to avoid overdraft.
Key idea
Eventual consistency lets balances scale by deriving them from async events, but money moving decisions must consult the authoritative ledger so a lagging projection never causes an overdraft.