Two concurrency terms that get confused constantly - here's the clean distinction.
🔹 Race condition: the outcome depends on unpredictable TIMING of operations. We saw this back in Spot the Bug #2 - two threads incrementing a shared counter, and depending on exact timing, updates get lost.
🔹 Deadlock: two or more threads are permanently stuck, each waiting for a resource the other one holds, forever.
Thread A: holds Lock 1, waiting for Lock 2
Thread B: holds Lock 2, waiting for Lock 1
→ Neither can ever proceed. Frozen forever.
The classic fix for deadlocks: always acquire locks in a consistent, agreed-upon order across your entire codebase. If EVERY thread always locks Resource 1 before Resource 2 (never the reverse), the circular waiting pattern above becomes structurally impossible.
Why this matters in interviews: system design and backend interviews increasingly probe concurrency understanding, even outside dedicated "concurrency" questions - e.g., "what happens if two requests try to update the same row at the same time?" is really asking about race conditions, often expecting you to mention database-level solutions like row locking or optimistic concurrency control (checking a version number before committing a write).
Race condition or deadlock - which one is scarier to debug in your experience, and why? 👇