Summary
Optimistic locking assumes conflicts are rare and checks at commit time. Pessimistic locking prevents conflicts by locking data before modification.
Interview Points
- Optimistic locking often uses version numbers or timestamps.
- Pessimistic locking uses database locks or exclusive access.
- Optimistic is better for read-heavy or low-conflict workloads.
- Pessimistic is safer for high-conflict critical sections.
- Locking strategy affects latency, throughput, and user experience.
2-3 Minute Interview Script
“Optimistic locking assumes conflicts are rare. A record has a version number, and when I update it, the database checks that the version has not changed. If it changed, my update fails and I retry or ask the user to resolve.
Pessimistic locking assumes conflicts are likely or costly. It locks the record before modification so other writers must wait.
Optimistic locking gives better concurrency for low-conflict systems like profile edits or content updates. Pessimistic locking can be appropriate for high-conflict workflows like limited inventory or financial ledger updates.
Interview answer: optimistic improves throughput when conflicts are rare; pessimistic protects correctness when conflicts are likely or expensive.”
Follow-Ups
- How do you implement optimistic locking?
- What causes deadlocks?