Concurrency Reasoning
Concurrency matters when operations can overlap across an invariant boundary. Identify the shared state and the atomic decision before choosing a lock, queue, transaction, or immutable model.
What you’ll understand
- Concurrency matters when operations can overlap across an invariant boundary. Identify the shared state and the atomic decision before choosing a lock, queue, transaction, or immutable model.
- Practice explaining a design decision with an example and a boundary case.
Find the check-then-act gap
Two callers can both observe one available item and then both decrement stock. Each method can look correct in isolation while the combined execution violates the invariant. Draw the interleaving and identify the point where checking availability and reserving must become one atomic operation.
- State the invariant: stock is never negative.
- List every shared field read and written.
- Show a failing interleaving before proposing a mechanism.
Match the mechanism to the boundary
An in-process lock protects threads sharing one memory space; it does not coordinate separate servers. A database conditional update can protect persisted stock. A single-owner queue can serialize commands. Retries need idempotency when a caller cannot tell whether a previous operation committed.
- Do not hold a local lock across an unbounded network call.
- Define lock ordering when several locks are necessary.
- Treat timeout as uncertainty rather than proof of failure.
State the limits of the walkthroughs
The interactive cases in this course are deterministic single-process models. They demonstrate validation and state transitions, not production synchronization. Use them to name the atomic operation, then explain how you would test concurrent callers in the deployment environment.
- What must happen exactly once from the business perspective?
- Can two independent operations proceed without sharing a lock?
- What recovery information must survive a crash?