3. Concurrency

Concurrency means multiple operations can overlap in time. If they read or change shared mutable state, race conditions can produce results that are individually valid but wrong together. Synchronization can protect shared state, but locks introduce contention and can create deadlocks. Prefer designs that reduce shared mutable state before adding more coordination.

Evidence: S4, S5, S6, S8

Request A: read stock = 1

Request B: read stock = 1

A: reserve 1

B: reserve 1

Result: two reservations for one item

Common tools

Atomic database update or constraint: often the simplest protection for shared persistent state.

Optimistic concurrency/version check: detect that somebody changed the record before you commit.

Lock/mutex/semaphore: coordinate access when operations truly must be serialized or bounded.

Queue/partition by key: process related work in order without globally serializing all work.

Immutability: reduces the amount of shared mutable state that needs coordination.

Evidence: S4, S5, S6, S8, S14

Checklist

• We identified operations that can run at the same time.

• We identified shared mutable state.

• Business invariants are protected under concurrent writes.

• Lost-update scenarios are handled.

• The chosen concurrency mechanism is at the correct layer (application, database, queue, etc.).

• Lock scope is as small as practical.

• If multiple locks are used, lock ordering is consistent to reduce deadlock risk.

• Long I/O is not performed while holding an in-process lock unless justified.

• Parallelism limits exist for scarce resources.

• Concurrency behavior is covered by targeted tests where the risk is material.

Evidence: S4, S5, S7, S8