What is balance caching?

Balance caching means you store the current total on the balance instead of summing the whole log on every read. The cache is the running number. The log is still the source of history. A cache you keep in Redis and never write back to the book is a second ledger, and it will lie.

How does balance caching work?

Each applied post updates a number on the balance row. A read returns that number. You do not scan every transaction to show a wallet. History still lives in the log. A historical read walks or reconstructs from that log as of a timestamp.

Balance cache vs a copy in Redis

A running total on the ledger row is part of the book. A copy you update in Redis after the API returns is a display cache. If the worker retries, or a void lands, the copy drifts. Read the ledger when the number can move money. Cache only what you can afford to be late.

What about hot balances?

A popular balance is slow because of writes, not because of the read of the cached total. Caching the number does not cool the row. Coalesce, shard, or stop sending every event through one pot.

Blnk stores credit, debit, inflight, and queued amounts on the balance. Use historical balances when you need the number as of a past time, not a copy you saved yourself.