Why Concurrency Shows Up in LLD Rounds
You'll learn to
- -Recognize the interview signal that a design needs thread-safety - shared mutable state accessed by concurrent actors
- -Identify the classic LLD problems (parking lot entry, ticket booking, rate limiters) where concurrency is the actual point of the question
Most LLD prompts are secretly two questions in one: can you design clean, extensible classes, and can you notice when this class diagram will break under concurrent access. A design that is architecturally beautiful but lets two threads assign the same parking spot to two different cars has failed the second, unstated question.
The Pattern That Signals "This Needs Thread-Safety"
The tell is always the same shape: multiple independent actors (users, requests, threads) competing for a limited, shared, mutable resource. A parking lot has a finite number of spots that many cars try to claim simultaneously. A movie booking system has a finite number of seats that many users try to reserve at once. A rate limiter has a shared counter that many requests increment concurrently. Whenever your design has "there are N of these, and more than N requesters might show up at once," concurrency is not an edge case - it is the core of the problem.
- -A single mutable counter or collection read and written by multiple actors (a rate limiter's request count, a cache's eviction list).
- -A finite pool of resources being claimed (parking spots, theater seats, database connections).
- -A multi-step "check, then act" sequence (check if a spot is free, then assign it) - the classic race-condition shape, since another thread can act between your check and your act.
The Check-Then-Act Race, Made Concrete
class ParkingLot:
def __init__(self, total_spots: int):
self.available_spots = total_spots
def assign_spot(self) -> bool:
if self.available_spots > 0: # CHECK
# <- another thread can run here, between check and act
self.available_spots -= 1 # ACT
return True
return False
# Two threads both read available_spots == 1, both pass the check,
# both decrement - available_spots ends at -1, and two cars were
# both told they got the same, only remaining spot.This is not a hypothetical - it is the default behavior of the naive version of this code under real concurrent load, and it is exactly the kind of bug a strong LLD answer catches before an interviewer has to point it out. The fix (locks, atomic operations, or restructuring so the check and the act happen as one atomic step) is the subject of the next chapter.
Noticing a concurrency issue out loud, even if you do not have time to fully implement the fix, is worth more in an interview than silently producing a design that happens to compile but has a race condition baked in.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.