Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.blnkfinance.com/llms.txt

Use this file to discover all available pages before exploring further.

This page covers the settings that control how Blnk executes, queues, batches, and routes transactions.

​
Transaction settings

Use these settings to control transaction batching, worker behavior, locking, and queued validation. 
BLNK_TRANSACTION_BATCH_SIZE=1000
BLNK_TRANSACTION_MAX_QUEUE_SIZE=1000
BLNK_TRANSACTION_MAX_WORKERS=10
BLNK_TRANSACTION_LOCK_DURATION=1800
BLNK_TRANSACTION_LOCK_WAIT_TIMEOUT=3
BLNK_TRANSACTION_INDEX_QUEUE_PREFIX=transactions
BLNK_TRANSACTION_ENABLE_QUEUED_CHECKS=false
DescriptionDefault
BLNK_TRANSACTION_BATCH_SIZEMaximum number of items Blnk processes in a single transaction batch.1000
BLNK_TRANSACTION_MAX_QUEUE_SIZEIn-memory channel buffer size for the batch worker used by ProcessTransactionInBatches (not a Redis queue depth limit).1000
BLNK_TRANSACTION_MAX_WORKERSConcurrency for batch and reconciliation transaction workers (e.g. ProcessTransactionInBatches). For the main Redis-backed queued transaction pool, use BLNK_QUEUE_TRANSACTION_WORKER_CONCURRENCY and hot-lane settings instead.10
BLNK_TRANSACTION_LOCK_DURATIONHow long a distributed balance lock can live once acquired, in seconds (non-zero values).1800
BLNK_TRANSACTION_LOCK_WAIT_TIMEOUTHow long Blnk waits when acquiring transaction balance locks (shared path for direct and queued processing, including coalesced batch execution), in seconds.3
BLNK_TRANSACTION_INDEX_QUEUE_PREFIXCollection / index name prefix for transaction search documents (e.g. Typesense), not a Redis transaction queue name.transactions
BLNK_TRANSACTION_ENABLE_QUEUED_CHECKSIncludes queued debits when loading balances for pre-transaction validation.false

​
BLNK_TRANSACTION_LOCK_WAIT_TIMEOUT

This controls how long a transaction should wait when acquiring a lock before the transaction fails with a lock error. If locks are not acquired in time, the operation fails with a lock error. For a direct (skip_queue=true) request, that is typically returned to the client. For queued work, workers may retry or reject depending on queue settings, e.g. BLNK_QUEUE_REJECT_LOCK_CONTENTION_IMMEDIATELY and BLNK_QUEUE_MAX_RETRY_ATTEMPTS.
Tip: Keep the default value unless transactions regularly outlive the lock window. This config is especially important for transactions that bypass the queue.

​
Coalescing settings

Use Coalescing settings to improve performance and throughput under load when working with hot balances. 
BLNK_TRANSACTION_BATCH_SIZE=1000
BLNK_TRANSACTION_ENABLE_COALESCING=true
BLNK_TRANSACTION_DISABLE_BATCH_REFERENCE_CHECK=false
DescriptionDefault
BLNK_TRANSACTION_BATCH_SIZEMaximum number of compatible queued transactions Blnk tries to process in one coalesced batch.1000
BLNK_TRANSACTION_ENABLE_COALESCINGEnables coalesced execution for normal queued transaction processing.true
BLNK_TRANSACTION_DISABLE_BATCH_REFERENCE_CHECKDisables reference validation across a coalesced batch before commit. When false, reference checking stays enabled.false

​
BLNK_TRANSACTION_ENABLE_COALESCING

When Coalescing is enabled, Blnk identifies the queued transactions based on if they share the same source, destination, and currency, batches them in-memory, and applies them in a single commit. This works best when queued traffic arrives in bursts and many transactions overlap on the same balances.

Coalescing for hot balances

Learn when to use coalescing and how it improves throughput for contended balance flows.

​
BLNK_TRANSACTION_DISABLE_BATCH_REFERENCE_CHECK

This controls whether Blnk validates transaction references across the batch before commit. Leaving it as false (the default) is safer because it helps catch duplicate or conflicting references within the same batch, ensuring that your transactions remain idempotent.
Please note: Disabling reference checks may reduce some overhead, but it also increases the risk of duplicate-reference issues slipping through batched execution.

​
Queue settings

Use these settings to control queue names, sharding, concurrency, retries, and worker monitoring for normal queued processing. 
BLNK_QUEUE_TRANSACTION=new:transaction
BLNK_QUEUE_NUMBER_OF_QUEUES=20
BLNK_QUEUE_TRANSACTION_WORKER_CONCURRENCY=1
BLNK_QUEUE_MAX_RETRY_ATTEMPTS=5
BLNK_QUEUE_INSUFFICIENT_FUND_RETRIES=false
BLNK_QUEUE_WEBHOOK=new:webhook
BLNK_QUEUE_INDEX=new:index
BLNK_QUEUE_INFLIGHT_EXPIRY=new:inflight-expiry
BLNK_QUEUE_WEBHOOK_CONCURRENCY=20
BLNK_QUEUE_MONITORING_PORT=5004
DescriptionDefault
BLNK_QUEUE_TRANSACTIONBase name used for normal transaction queue shards.new:transaction
BLNK_QUEUE_NUMBER_OF_QUEUESNumber of normal transaction queue shards used for queued work.20
BLNK_QUEUE_TRANSACTION_WORKER_CONCURRENCYWorker concurrency for normal transaction queues.1
BLNK_QUEUE_MAX_RETRY_ATTEMPTSMaximum number of retries for queued transaction failures.5
BLNK_QUEUE_INSUFFICIENT_FUND_RETRIESControls whether insufficient-funds failures are retried instead of rejected immediately.false
BLNK_QUEUE_WEBHOOKQueue name used for webhook tasks.new:webhook
BLNK_QUEUE_INDEXQueue name used for indexing tasks.new:index
BLNK_QUEUE_INFLIGHT_EXPIRYQueue name used for inflight-expiry tasks.new:inflight-expiry
BLNK_QUEUE_WEBHOOK_CONCURRENCYWorker concurrency for webhook and index tasks.20
BLNK_QUEUE_MONITORING_PORTPort used for worker monitoring and metrics.5004

​
BLNK_QUEUE_NUMBER_OF_QUEUES

Blnk hashes the source balance ID and assigns the transaction to one of the configured queue shards. More queues allow more unrelated balances to process in parallel. This helps reduce collisions before execution, but it does not replace locking. If many transactions still target the same balances, increasing the shard count alone will not solve the hotspot. See instead: How to handle hot balances.

​
BLNK_QUEUE_TRANSACTION_WORKER_CONCURRENCY

This controls how many normal queued transaction tasks can execute at the same time. Higher concurrency can improve throughput when work is spread across unrelated balances. It can also increase lock contention when many tasks overlap on the same balances. Increase it gradually and watch for contention before raising it further.

​
BLNK_QUEUE_MAX_RETRY_ATTEMPTS

This sets the maximum number of times Blnk will try a queued transaction again after a temporary failure such as lock contention, insufficient funds, etc. In simple terms:
  • If a queued transaction fails for a reason that may clear on its own, Blnk can try it again
  • If it keeps failing, Blnk stops after this limit instead of retrying forever.

​
BLNK_QUEUE_INSUFFICIENT_FUND_RETRIES

This controls whether Blnk should retry queued transactions that fail because the source balance does not have enough funds. Leave this disabled when an insufficient-funds result should be treated as final. Enable it only when the balance may change shortly after the first attempt, for example:
  • another queued credit is still being processed
  • funds are expected to arrive from another part of your workflow
  • transaction ordering means the balance may be sufficient on a later retry

​
Hot-lane routing settings

Use these settings to isolate repeatedly contended balance pairs into a dedicated queue. 
BLNK_QUEUE_ENABLE_HOT_LANE=false
BLNK_QUEUE_HOT_QUEUE_NAME=hot_transactions
BLNK_QUEUE_HOT_QUEUE_CONCURRENCY=1
BLNK_QUEUE_HOT_PAIR_TTL=300
BLNK_QUEUE_HOT_PAIR_LOCK_CONTENTION_THRESHOLD=3
BLNK_QUEUE_REJECT_LOCK_CONTENTION_IMMEDIATELY=false
DescriptionDefault
BLNK_QUEUE_ENABLE_HOT_LANEEnables hot-lane routing for repeatedly contended balance pairs.false
BLNK_QUEUE_HOT_QUEUE_NAMEQueue name used for hot-lane traffic.hot_transactions
BLNK_QUEUE_HOT_QUEUE_CONCURRENCYWorker concurrency for the hot queue.1
BLNK_QUEUE_HOT_PAIR_TTLHow long hot-pair activity and contention state is remembered, in seconds (see note at top of this page).300
BLNK_QUEUE_HOT_PAIR_LOCK_CONTENTION_THRESHOLDNumber of contention events required before a pair is promoted into the hot lane.3
BLNK_QUEUE_REJECT_LOCK_CONTENTION_IMMEDIATELYRejects queued transactions immediately after lock-contention failure instead of retrying them.false

​
BLNK_QUEUE_ENABLE_HOT_LANE

Hot-lane routing is Blnk’s contention-aware queue routing strategy. Blnk tracks repeated lock-contention events for a specific source|destination|currency pair. When contention crosses the configured threshold, BLNK_QUEUE_HOT_PAIR_LOCK_CONTENTION_THRESHOLD, Blnk promotes that pair into a hot state. New queued transactions for that pair are then routed to a dedicated hot queue instead of the normal queue shards. This helps isolate the hottest balance pairs from the rest of your queued traffic, so they stop disturbing normal queue processing.

​
BLNK_QUEUE_REJECT_LOCK_CONTENTION_IMMEDIATELY

This setting changes what queued workers do after a lock-contention failure. When set to true, Blnk rejects the transaction immediately if the required lock is busy. When set to false, the worker treats the failure as retryable and retries it up to BLNK_QUEUE_MAX_RETRY_ATTEMPTS.
Please note: This setting does not affect skip_queue=true transactions.

​
Best practices

  • Enable hot-lane routing when only a few balance pairs keep colliding.
  • Use a shorter TTL for short bursts so pairs return to the normal queue sooner after traffic settles. Use a longer TTL when the same pairs stay hot for longer periods.
  • Lower the threshold if hot pairs are not moving into the hot lane fast enough. This makes Blnk promote contended pairs sooner instead of letting them keep slowing down the normal queue.
  • Only enable immediate rejection when you do not want Blnk to retry lock-contention failures.

​
Need help?

We are very happy to help you make the most of Blnk, regardless of whether it is your first time or you are switching from another tool. To ask questions or discuss issues, please contact us or join our Discord community.
Tip: Connect to Blnk Cloud to see your Core data.You can view your transactions, manage identities, create custom reports, invite other team members to collaborate, and perform operations on your Core — all in one dashboard.Check out Blnk Cloud →