Tagged concurrency
3 pieces
- · 10 min read
Moving An Allocation Is A Transition, Not An Edit To Two Quantities
Shifting an allocation from one commitment to another moves real exposure, so it has to be recorded as its own transition with its own entry. Implemented as an edit to two numbers it leaves nothing to reconstruct, which means the move cannot be explained when it is challenged and cannot be made safe when two people do it at once. The operation is the record, not the resulting quantities.
- · 11 min read
Concurrency Belongs at the Write, Not at the Read
Under ordinary database isolation levels two concurrent requests can both read the same available balance, both find it sufficient, and both commit, leaving the balance negative. Checking availability before the write cannot prevent it, because the check and the write are separate decisions taken against a stale view. Enforce the constraint where the write lands: a uniqueness constraint, a conditional update, or explicit locking.
- · 7 min read
Bound the Concurrency or Your Latency Problem Becomes a Refusal
Running independent calls concurrently is the right instinct, and unbounded concurrency converts a slow path into a failing one. Without a ceiling, a wide request exhausts connection pools and trips provider rate limits under exactly the load where it matters most. With a ceiling, the same load produces a slower response that still completes. Turning a failure mode into a latency mode is almost always the correct trade in a user-facing path.