Concurrency bugs are among the hardest to reproduce and fix because they depend on timing. The core problem is almost always the same: shared mutable state. Two threads read and write the same data, and the interleaving of operations produces corrupted results. Let's look at the patterns that prevent this.

The Problem: Race Conditions. Imagine a web service tracking inventory. Two requests arrive simultaneously to purchase the last item:

• Thread A reads stock = 1
• Thread B reads stock = 1
• Thread A writes stock = 0, fulfills order
• Thread B writes stock = 0, fulfills order

You've now sold two items when you had one. This is a check-then-act race condition, and it happens in production more often than anyone admits.

Pattern 1: Immutability. If data never changes after creation, concurrent reads are always safe. In practice, this means returning new objects instead of mutating existing ones. Languages like Rust enforce this at compile time; in Java or Python, you use frozen dataclasses, records, or Object.freeze(). Rule of thumb: if a value crosses thread boundaries, make it immutable by default.

Pattern 2: Confinement. Instead of sharing data, give each thread its own copy. Message-passing architectures (Go channels, Erlang processes, actor model) follow this principle. The inventory problem becomes: a single actor owns the stock count, and requests are serialized through its message queue. No locks needed because there's no sharing.

Pattern 3: Atomic Operations. For simple counters or flags, use atomic compare-and-swap (CAS) operations. Most languages expose these: AtomicInteger in Java, atomics in C++, Interlocked in .NET. They're lock-free and fast, but only work for single-variable updates.

Pattern 4: Locks (Last Resort). When you must share mutable state across threads, protect it with a mutex. But locks introduce their own problems: deadlocks (A waits for B, B waits for A) and priority inversion. Follow the lock ordering rule: always acquire multiple locks in the same global order. If every thread locks resource X before resource Y, deadlock between X and Y is impossible.

A practical rule of thumb: the probability of a race condition manifesting is roughly proportional to the number of concurrent requests multiplied by the time the critical section is exposed. If you handle 1,000 req/s and your unprotected read-modify-write takes 2ms, you can expect collisions within minutes, not months. Cut the window to microseconds with atomics, or eliminate it entirely with confinement.

When debugging suspected concurrency issues, add thread IDs to your logs and look for interleaved operations on the same resource. Tools like ThreadSanitizer (C++/Go) and Java's -XX:+FlightRecorder can detect races before they hit production.