Dealing with Contention

Patterns # Dealing with Contention Learn about how to deal with high contention in your system design interview.Dealing with ContentionUpdated Jun 5, 2026 🔒 **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