High-Volume Crypto Payments: Scaling Paychainly to 10,000 Transactions Per Day

Bottleneck Analysis

At 10,000 tx/day (~0.1 tx/s average, 10× peak = 1 tx/s), the bottlenecks are: (1) RPC rate limits, (2) sweep concurrency, (3) PostgreSQL write throughput, (4) Redis queue depth.

RPC Pool Scaling

At 1 tx/s, each sweep triggers ~6 RPC calls. That's 6 req/s sustained. Most public RPCs allow 50–100 req/s per IP. Use 3–5 endpoints in your RPC pool with load balancing:

-- Add premium endpoints with higher priority
INSERT INTO rcps (rpcUrl, priority, forListener, forTransaction)
VALUES ('https://bsc.drpc.org', 1, true, true);

BullMQ Concurrency Tuning

# .env — increase for higher throughput
BULLMQ_CONCURRENT_CONCURRENCY=20    # block-filter + tx-process
SWEEP_CONCURRENCY=10                 # parallel sweeps (each address still serialized)

PostgreSQL Indexes

-- Ensure these indexes exist for common query patterns
CREATE INDEX IF NOT EXISTS idx_transactions_user_created
  ON transactions (user_id, created_at DESC);

CREATE INDEX IF NOT EXISTS idx_deposit_addresses_address
  ON deposit_addresses (address);

CREATE INDEX IF NOT EXISTS idx_block_audit_block_number
  ON block_audit (block_number);

Redis Optimization

• Use a dedicated Redis instance for BullMQ (set REDIS_DB=1).
• Enable Redis persistence (AOF) to survive restarts without losing queued jobs.
• Monitor memory with redis-cli info memory; set maxmemory-policy allkeys-lru.

Horizontal Scaling

Run multiple api instances behind a load balancer. All queue workers share the same Redis — BullMQ distributes jobs automatically. Only ensure a single BlockDiscoveryService runs (use a leader election lock or disable discovery on worker-only instances).