Patterns
Dealing with Contention
Learn about how to deal with high contention in your system design interview.
Dealing with Contention
🔒 Contention occurs when multiple processes compete for the same resource at the same time, like booking the last concert ticket or bidding on an auction item. Without proper handling, you get race conditions, double-bookings, and inconsistent state.
The Race Condition
Consider buying concert tickets online. There's one seat left for The Weeknd, and Alice and Bob both want it. They each hit "Buy Now" in the same instant. The obvious way to handle a purchase is the one most of us would reach for first. Read the current seat count, check that it's above zero, and if it is, decrement it and sell the ticket.
-- Read the current count
SELECT available_seats FROM concerts WHERE concert_id = 'weeknd_tour';
-- The app checks available_seats > 0, then writes the new value back
UPDATE concerts
SET available_seats = available_seats - 1
WHERE concert_id = 'weeknd_tour';For a single buyer this is exactly right. The trouble starts when Alice and Bob run it at the same moment. Alice's request reads one seat available. A fraction of a millisecond later, before Alice has written anything back, Bob's request reads the same count and also sees one seat. Both check the number they just read, both conclude there's a seat to sell, and both move on to charge a card. Alice's update commits first and the count drops to zero. Bob's update commits right after, decrements again, and the count slides to negative one.
By the time the dust settles, both cards have been charged $500 and both buyers have a confirmation email for the same seat. Alice and Bob show up to the concert each thinking they own Row 5, Seat 12. One of them is getting kicked out, and the venue is stuck issuing a refund while dealing with two very angry customers.
Race Condition Timeline
The Solution
Conditional Writes
Pessimistic Locking
Common Failure Modes
Optimistic Concurrency Control
Isolation Levels
Distributed Locks
Choosing the Right Approach
When to Use in Interviews
Recognition Signals
Common Interview Scenarios
When NOT to overcomplicate
Common Deep Dives
"How do you prevent deadlocks with pessimistic locking?"
"How do you handle the ABA problem with optimistic concurrency?"
"What about performance when everyone wants the same resource?"
Conclusion
Purchase Premium to Keep Reading
Unlock this article and so much more with Hello Interview Premium
Currently up to 20% off
Hello Interview Premium
Reading Progress
On This Page
The Race Condition
The Solution
Conditional Writes
Pessimistic Locking
Optimistic Concurrency Control
Isolation Levels
Distributed Locks
Choosing the Right Approach
When to Use in Interviews
Recognition Signals
Common Interview Scenarios
When NOT to overcomplicate
Common Deep Dives
"How do you prevent deadlocks with pessimistic locking?"
"How do you handle the ABA problem with optimistic concurrency?"
"What about performance when everyone wants the same resource?"
Conclusion