Thread-safe components, lock granularity, and immutable-object strategies.
6 questions in Low-Level Design & OOD.
For one stock counter, optimistic locking with a compare-and-set loop fits: read, refuse at zero, and publish the decrement only if nobody changed the value meanwhile. A lock suits a larger critical section. Prove it by arguing each sale consumes one unit, plus a stress test seen to fail on the broken code.
The bug is a check-then-act race condition: both threads see the seat free before either marks it taken. The lock must cover the check and the write together, scoped to one show so unrelated shows never wait, and released before payment, with a timed hold standing in for the seat while the user pays.
Shrink the critical section first, then replace the global lock with lock striping, a fixed array of locks keyed by resource hash. Lock ordering by ascending stripe index rules out deadlock for multi-resource bookings, tryLock bounds waiting, and invariants the old lock covered by accident each need an owner.
Thread-safe component design starts by assigning every field a policy: confined, immutable or guarded by a named lock. Method-level synchronization is not enough because atomic methods do not compose into atomic workflows.
A producer-consumer bounded buffer applies backpressure to the producer instead of letting an unbounded queue absorb overload until the process dies. Deciding what a full buffer does - block, drop, or reject - is the decision that determines how the system fails.
A deadlock is a cycle in the wait-for graph, so the design goal is a graph that cannot contain one: stop holding two locks where you can, impose one total order on acquisition everywhere you cannot, and never call unknown code while holding a lock.