Overview
“Hot balances” are ledger balances that perform high volumes of concurrent transactions. These balances can experience lock contention when using immediate processing (skip_queue: true), leading to transaction failures and poor user experience.
This guide covers strategies for handling hot balances effectively in Blnk, ensuring reliable transaction processing even under high load.
Understanding the problem
When multiple transactions target the same balance simultaneously usingskip_queue: true, they must acquire distributed locks to maintain balance integrity. If a lock isn’t acquired, the transaction fails with a Failed to acquire lock error.
This becomes problematic for hot balances that receive:
- High-frequency payments from multiple customers
- Batch processing operations
- Real-time transaction streams
- Popular accounts with frequent activity
Solution strategies
Option 1: Use the queue (recommended)
The most reliable approach for hot balances is to use Blnk’s built-in queuing system:
Remove skip_queue parameter
When creating transactions for hot balances, omit the
skip_queue parameter or set it to false. This routes transactions through the queue system.Listen for webhook events
Set up webhooks to receive real-time updates when transaction status changes:Common webhook events:
transaction.applied- Transaction successfully processedtransaction.rejected- Transaction rejected (insufficient funds, etc.)transaction.inflight- Transaction held in inflight state
Option 2: Handle concurrency on your end
If you must useskip_queue: true for hot balances, implement your own concurrency controls to prevent race conditions:

Implement sequential processing
Ensure transactions are sent one after another, not simultaneously. Avoid sending all transactions at once and instead process them sequentially to prevent lock contention.
Option 3: Use intermediary balances
Introduce intermediary balances in your money movement map to reduce load on hot balances: Instead of:Customer balance → GL Balance
Use: Customer balance → Customer hold balance → GL Balance

Create customer hold balances
Each customer gets their own hold balance that acts as a buffer. Create separate hold balances for each customer to isolate their transactions.
Process customer transactions immediately
Customer transactions can safely use
skip_queue: true since each customer has their own hold balance, eliminating competition for locks.- Each customer gets their own hold balance, eliminating competition for locks;
- Customer transactions process immediately for better UX;
- GL balance receives fewer, larger transactions via queue;
- Provides flexibility in processing high-traffic transactions.