80/20 Of The Week … Locking (Optimistic, Pessimistic, …)
Concurrency is one of those things that does not look scary at first.
If a system has one user, or very little traffic, many issues barely show up.
But once multiple users or requests start touching the same resource at the same time things get interesting very quickly.
For example:
- two users update the same row
- two requests try to buy the last item
- two services modify the same data almost simultaneously
Life if an item has stock = 1, and now two users try to buy it at almost the same time and without proper concurrency control, both requests may read stock = 1, both think the item is available, and both try to update it.
That is where concurrency problems begin and one of the most common ways to deal with them is locking.
Locking is a broad term used in different places across programming and system design, but one very common place you will see it is in databases.
That is where optimistic and pessimistic locking usually come in.
- Why locking matters Without proper control, concurrent operations can cause problems like:
- lost updates
- dirty reads
- inconsistent state
- race conditions
A system may look fine in development and then break in production simply because multiple users are now doing things at the same time.
- Pessimistic locking Pessimistic locking assumes conflicts are likely. So instead of hoping nobody else touches the same data, it locks it early.
The idea is basically: “I am working with this row now, others should wait.”
In databases, this often looks like:
SELECT … FOR UPDATE
That means one transaction locks the row, and other transactions trying to modify it must wait. This is safer when contention is high but it can also reduce throughput and increase waiting.
- Optimistic locking Optimistic locking assumes conflicts are rare.
So instead of locking immediately, it allows multiple transactions to proceed…
but checks before commit whether someone else changed the data first.
This is often done with a:
- version column
- timestamp
- update counter
The flow is usually:
-read row with version = 5 -make changes -try update where version is still 5 -if it changed already, fail and retry
The idea is: “Let people work freely, but detect conflicts before overwriting.”
This usually scales better when collisions are uncommon.
- So which one is better? Neither is “better” in all cases.
Pessimistic locking is better when conflicts are frequent and correctness matters immediately Optimistic locking is better when conflicts are rare and you want better throughput
So the choice depends on access patterns, contention, and business rules.
- Main takeaway Concurrency problems do not appear because systems are complicated.
They appear because multiple things happen at the same time.
And locking is one of the main ways we stop those things from corrupting shared state.
That is why optimistic and pessimistic locking matter:
they are two different ways of answering the same question…
What should happen when multiple actors touch the same data at once?
#Backend #Databases #Concurrency #SystemDesign #Transactions #SQL #SoftwareEngineering
