Credit ledger

The double-entry idea applies directly. The balance is not a field that gets overwritten; it is the sum of immutable entries, each with an amount, a reason and a reference to what caused it. Recomputing the balance from the entries and comparing it to the stored value is a cheap integrity check that catches a whole class of accounting bugs.

Usage billing needs a hold-and-settle flow because the cost is unknown in advance. At dispatch, an estimated amount is moved from available balance into a held state, which prevents a workspace from starting more concurrent calls than it can pay for. When the call ends, the hold is settled against actual usage, or released in full if the call never connected. The invariant worth enforcing is that available plus held is unchanged by a hold or a release.

Concurrency is where naive implementations break. Two simultaneous dispatch requests that each read the balance, decide it is sufficient, and then write can both succeed and overdraw the account. The fix is to make the reservation a single conditional operation that only applies if the balance still covers it, letting the database serialise competing requests rather than the application.