Build fluency in the vocabulary of two concurrent operations silently corrupting shared state.
0 / 5 completed
1 / 5
At standup, a dev mentions two requests reading a counter's current value, each incrementing it locally, and each writing back, so one of the two increments is silently lost because neither read saw the other's write. What is this bug called?
A race condition happens exactly here: two requests each read the same counter value, increment their own local copy, and write back, and whichever write happens second simply overwrites the first, silently losing one of the two increments. A deadlock is a different failure mode entirely, where threads are blocked rather than corrupting shared state. This kind of lost update is one of the most common race conditions in any system where more than one process reads, modifies, and writes back shared state without coordination.
2 / 5
During a design review, the team wants the counter increment to happen as a single atomic read-modify-write operation, so no other request can read a stale value in between. Which capability supports this?
An atomic increment operation, or a compare-and-swap loop that retries if the value changed underneath it, combines the read and the write into a single indivisible step, so no other request can slip in a conflicting read between them. Continuing to read, increment, and write as three separate steps is exactly the pattern that allows two concurrent requests to interleave and lose an update. This atomicity is the standard fix for a race condition on a single shared value like a counter.
3 / 5
In a code review, a dev notices a function checks whether a file exists and then, in a separate later step, opens it, with another process able to run in between those two steps. What does this represent?
This is a classic time-of-check to time-of-use (TOCTOU) race condition, since the file's state can change in the gap between the existence check and the later open, for instance if another process deletes or replaces it in between. A cache eviction policy is an unrelated concept about discarded cache entries. This TOCTOU pattern is a well-known category of race condition that shows up whenever a check and its corresponding action aren't performed as a single atomic step.
4 / 5
An incident report shows two concurrent checkout requests both read a product's stock as one unit remaining and both proceeded to complete the sale, resulting in the same last unit being sold twice, because the stock check and the decrement weren't combined into one atomic operation. What practice would prevent this?
Performing the stock check and the decrement as a single atomic operation, such as a conditional update that only succeeds if the stock is still at least one, closes the gap where two concurrent requests could both read the same value before either one writes. Continuing to treat the check and the decrement as separate steps is exactly what allowed the same last unit to be oversold in this incident. This atomic check-and-decrement pattern is the standard fix for a race condition on any resource with limited availability.
5 / 5
During a PR review, a teammate asks why the team wraps a shared counter's read-modify-write sequence in an atomic operation instead of just trusting that two requests are unlikely to arrive at nearly the same moment. What is the reasoning?
Under real production load, two requests arriving close enough together to interleave stops being a rare edge case and becomes a routine occurrence, since higher concurrency directly increases the odds of two operations overlapping in exactly the vulnerable window. An atomic operation removes the possibility of a lost update entirely, regardless of how much concurrent traffic the system sees. The tradeoff is the added complexity, and sometimes contention overhead, of wrapping every shared-state update in an atomic primitive instead of writing the simpler, unsafe three-step version.