What is queuing in a ledger?

Queuing means the ledger accepts a transfer now and applies it later. The request is stored as work. A worker picks it up, locks the balances, and posts. The HTTP response is a receipt, not a commit. If you treat queued as settled, two callers will spend the same money.

How does queuing work?

You send source, destination, amount, and a reference. The ledger writes a queued record and returns. A worker later applies that record. The queued row is the parent of the applied, rejected, or inflight row. Look up the next state by parent, not by assuming the first id is final.

Queued vs inflight vs applied

Queued means the worker has not run. Inflight means the worker ran and the amount is held for commit or void. Applied means settled balances moved. A payout to ACH is often queued, then inflight, then applied. Skipping those words in your app state is how “pending” comes to mean three different things.

When do you skip the queue?

When you need the apply in the same request and the balances are not hot. Skipping the queue does not skip locks. It just does the work before you return. Use it for low-volume paths you must show as done in one round trip. Leave the queue on for everything that can collide.

In Blnk the default is queued. Set skip_queue: true only when you need a synchronous apply. See transaction lifecycle and concurrency.