Concurrency, in DB management, is a situation where a row or a piece of data living in a database, is being accessed by multiple users at the same time with the purpose of reading/updating/deleting it.
This obviously can lead to conflicts and inconsistencies.
There are 2 broad ways of dealing with such conflicts: Optimistic concurrency and Pessimistic concurrency.
Simply put, Optimistic concurrency means allowing concurrent edits/updates without blocking it just because some else is working on it, with the optimism that it will all work out in the end with proper conflict handling.
Pessimistic concurrency means NOT allowing concurrent edits/updates by blocking it because some else is working on it, with the pessimism that it will all NOT work out in the end.
AI generated analogy:
📚 The Setting
Lila and Mohan are librarians working in the same library.
They both need to update the same library book card — the card for “The Hobbit”.
The library allows two different ways of handling such situations:
- Pessimistic concurrency 🔒
- Optimistic concurrency 🌿
🔒 1. Pessimistic Concurrency — Lock First, Work Alone
Lila goes to update the card for “The Hobbit.”
She takes the original card from the filing cabinet, puts it on her desk, and locks it in her drawer while she works.
Mohan comes by a few minutes later. He also wants to make a change to “The Hobbit.”
The librarian says:
“❌ Sorry, Lila is working on that card. You’ll have to wait until she’s done.”
So Mohan just stands by until Lila finishes.
When she’s done, she puts the card back, unlocks it, and now Mohan can take it and make his edits.
👉 Key idea:
- Only one person can work on the card at a time.
- Conflicts are prevented upfront because nobody else is allowed to touch the card while it’s “checked out.”
- But it means others (like Mohan) might have to wait.
🧠 This is pessimistic concurrency:
“Let’s lock the data immediately so no one else can mess with it while I’m working.”
🌿 2. Optimistic Concurrency — Work Freely, Check Later
Now imagine a different approach.
Lila goes to update the same card. Instead of taking the original, she photocopies it. She works on the copy at her desk.
At the same time, Mohan also goes to update the same card. He too takes his own photocopy and works on it independently.
Neither of them blocks the other. They both happily make their edits at the same time.
Later, both return to the librarian to apply their changes to the original card.
- Mohan returns first and updates the original card. The librarian stamps the card “Version #6.”
- Lila comes a bit later with her changes based on the older Version #5.
The librarian checks:
“Hmm, this card is already at Version #6.
Lila, you’re trying to apply edits to Version #5. Someone else has changed this in the meantime.”
Now, there are three possible ways the librarian handles this:
- 🚫 Reject Lila’s update — “Please take the latest card and reapply your changes.”
- 📝 Ask Lila to manually merge her edits with the new Version #6.
- 🤖 Automatically merge the changes if they don’t conflict (e.g., Lila changed the title, Mohan changed the author).
👉 Key idea:
- Multiple people can work simultaneously.
- Conflicts are detected later when they try to save.
- Nobody is blocked while editing, but the system must check versions to catch conflicts.
🧠 This is optimistic concurrency:
“Let’s trust that things will work out, let everyone work in parallel, and handle any conflicts after they happen.”
Top comments (0)