Concurrency Control: The Hidden Battle for Resources in Distributed Systems

✈️ Ever tried to book the last seat on a flight… only to see it vanish before checkout?

You both clicked "Book Now" at the same millisecond.
Only one of you should win—but if your system isn’t designed right, both might get confirmations.

This isn’t just bad UX.
This is concurrency control—the difference between software that works and software that lies.

---

💣 The Real-World Problem

Imagine:

• 10,000 users racing to book 100 seats

• All sending POST /book requests within milliseconds

• The database sees parallel transactions fighting for the same row

Critical questions:

1. 🧨 What stops the same seat from being sold twice?

2. 🧨 What if a user refreshes mid-transaction?

3. 🧨 What if two bookings finish almost simultaneously?

---

🧠 How Modern Systems Handle This

🔒 1. Pessimistic Locking: "Mine First!"

• How it works:

  • User A queries Seat A1 with an exclusive lock (SELECT ... FOR UPDATE)

  • User B blocks until User A commits or rolls back

• Best for: High-contention systems (ticketing, banking)

• Tradeoffs:
  ✅ Guaranteed correctness
  ⚠️ Deadlocks possible (User A locks Seat 1, User B locks Seat 2, both wait forever)
  ⚠️ Poor horizontal scaling (threads wait in line)

Example:

sql

BEGIN;
SELECT * FROM seats WHERE id = 42 FOR UPDATE; -- Lock acquired
-- Process payment, update booking status
COMMIT; -- Lock released

---

🔁 2. Optimistic Concurrency Control: "Hope & Check"

• How it works:

  • All users read the seat’s current version

  • At commit time:

    sql

      UPDATE seats SET status = 'booked', version = version + 1 
      WHERE id = 42 AND version = 5; -- Fails if someone else updated first
    

  • If conflicted → retry or fail gracefully

• Best for: Lower-contention systems (e-commerce carts, collaborative editing)

• Tradeoffs:
  ✅ No blocking → high throughput
  ⚠️ Requires retry logic (exponential backoff recommended)

Used by:

• Git (merge conflicts)

• Google Docs (collaborative editing)

• Vector databases (concurrent updates)

---

📦 3. Transaction Isolation Levels: "How Consistent Should My View Be?"

Example:

sql

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
-- Transaction sees a consistent snapshot
COMMIT;

---

💥 4. Deadlock Detection & Retry

• Scenario:

  • User A locks Seat 1 → Seat 2

  • User B locks Seat 2 → Seat 1
    → Deadlock!

• Solution:

  • Databases detect cycles in lock waits

  • Abort one transaction (with ERROR: deadlock detected)

  • Retry with backoff (e.g., 100ms → 200ms → 400ms)

---

🚧 Where I’ve Fought These Battles

Case 1: Cloud Vector Database

• Problem: Cluster creation must have unique names

• Solution: Pessimistic locks on naming service

Case 2: Real-Time Deploy System

• Problem: Concurrent log writes + DB updates

• Solution: Optimistic versioning + SERIALIZABLE for critical sections

---

✅ Key Takeaways for Engineers

1. Pessimistic locking when correctness > scalability (e.g., ticket booking)

2. Optimistic concurrency when scalability > strict consistency (e.g., shopping carts)

3. Choose isolation levels wisely—higher consistency = lower throughput

4. Always handle retries (deadlocks will happen)

---

🎯 Interview Pro Tip

Don’t just say "I’ll use a transaction." Say:

"For seat booking, I’d use pessimistic locking with row-level locks*, **READ COMMITTED isolation*, and *exponential backoff retries for deadlocks. For less critical systems like inventory, optimistic versioning** reduces contention."*

This shows depth—exactly what interviewers want.

---

🚀 Final Thought

Concurrency control isn’t about avoiding bugs.
It’s about ensuring correctness when 10,000 users hit your system at once.

Agree? Have war stories? Drop them in the comments!

#SystemDesign #Concurrency #Database #BackendEngineering #TechInterviews

---

🔗 Want a deep dive on distributed locks? Upvote (👍) and I’ll cover it next!