What is ACID in a ledger?

ACID is four rules that keep a database write trustworthy: atomicity, consistency, isolation, and durability. In a ledger they mean a post either lands on both sides or on neither, the book stays balanced, two posts cannot corrupt the same balance, and a committed write survives a crash. A payment API that returns 200 is not the same thing as an ACID apply.

How does ACID work in a ledger?

Atomicity keeps the debit and the credit together. Consistency keeps the invariants you set, such as “this wallet cannot go below zero.” Isolation stops two concurrent posts from reading a stale total and both applying. Durability means the applied row is on disk before you treat it as money.

ACID vs a 200 from the API

Many ledgers accept work, queue it, and apply it later. The accept is not the apply. If you credit a customer on the HTTP response, you are treating a receipt as a commit. Wait for the applied record, or hold the amount inflight until you decide.

What breaks without it?

Two payouts read the same available balance and both leave. A crash after the debit and before the credit invents money. A retry without a unique reference posts twice. ACID is the write. The reference is the door.

Blnk accepts a transfer as queued, then a worker applies it under locks so the balance write is atomic. The applied row is the commit. See transaction lifecycle and concurrency.