Ask HN: Scaling to 100k outgoing transfers per account per hour

We're growing quickly and are running into scaling issues. We'd love to get some advice from the hackernews community on our biggest problem:

We're a payments startup that provides APIs to send and receive money. When our customers send an instruction to disburse funds through our API, a few things happen:

1. Acquire lock on customer account

2. Check if customer's balance is sufficient

3. Deduct customer balance

4. Release lock on customer account

5. Disburse the funds through our banking channels

As we continue to grow, this process of checking balance and deducting customer balance is becoming our main bottleneck. We've already implemented parallel processing for transactions in different accounts but the speed of steps 1-4 is impacting performance.

We are now exploring solutions that can combine steps 1-4 together, ideally using a database like MySQL that already has these capabilities.

The constraints we're working under are:

1. Transactions for each account must be processed sequentially, in the same order that they arrived in

2. Transactions for different accounts should be fully parallelized

3. We want to be able to process at least 100k transactions per account per hour

4. We want to be able to process transactions in band with the HTTP request, with latency <10ms

5. ACID

6. Auditable

We think that some flavor of SQL is the right direction but would appreciate your feedback/advice on what you think the best solution to our problem might be.