What is Concurrency Control?

How Does Concurrency Control Work?

To look at a real-world example, imagine that Sally and Jenna are both shopping for the same dress. Sally lives in South Africa and Jenna lives in Canada, but they can both visit the same website at the same time–neither will be unable to visit the website simply because the other is looking at it, too. Sally and Jenna are also both able to view the exact same dress at the same time, put the same dress into both of their carts, and even check out and purchase the dress simultaneously.

The website is able to support both Sally and Jenna viewing the dress, carting the dress, and can also check inventory to ensure there is enough stock for them to both purchase the dress, concurrently and in real-time. If, however, there was only one dress left in stock, concurrency controls on the website would only allow the buyer who completed the transaction first to purchase the dress. Without concurrency controls on the website, it would be possible for an oversell to occur in the case that both Sally and Jenna tried to buy the only dress left in stock at the same time.

While this is an oversimplified metaphor for concurrency controls, it provides the general idea: multiple functions in a program need to be able to happen simultaneously without interfering with each other.

Why Does Concurrency Control Matter?

When using a database, concurrency control is important to ensure that more than one call can be made to the database at the same time without any adverse effects. In terms of companies using a financial ledger database, concurrency control is even more significant because it allows for multiple different financial transactions to occur at once.

Let's say we run a peer-to-peer payment app like Venmo, as an example. In this example, we’ll use Modern Treasury’s Ledgers API as a database for recording financial transactions.

If Lucy Ledger was to transfer $50 to John Journal, we'd create a ledger transaction to debit Lucy's account and credit John's. Ledgers uses double-entry accounting to ensure that Lucy's balance decreases by the same $50 that John's increases.

In this instance this is a straightforward transaction to track, since there was only one request to debit Lucy. But what if we had a situation where there were multiple, concurrent requests to debit Lucy's account? How can we ensure that her balance doesn't go negative?

A less direct solution would be to fetch the balance of Lucy's account to check whether there is a sufficient balance before actually attempting the debit.

Below are two examples of balance requests before attempting the $50 debit:

This solution works, provided that we can guarantee that a request to debit the account doesn't happen in between these requests. But there is no real way to make that guarantee.

To solve the problem of overdrawing Lucy’s account, we’d need to implement some kind of concurrency control method. (For a more detailed look at how Modern Treasury, specifically, prevents Lucy’s account from being overdrawn, read this article.)

To learn more about Ledgers, check out these additional resources:

• What's the Difference Between a Financial Ledger Database and a General Ledger?
• Three Questions to Consider When Setting Up Ledgers
• Why Idempotency Matters in Payments
• What is Double-Entry Accounting?