What concurrency-friendly structures forbid

Which guarantees can no concurrent design give, and in what order should the escapes be tried?

What this group forbids

Shared mutable state and linear scalability cannot coexist. The coherency term is quadratic, and no implementation removes it. Only designs that avoid sharing do.
You cannot free memory in a lock-free structure without a reclamation protocol.
You cannot bound tail latency with lock-freedom. Only wait-freedom does that.
You cannot make readers free without either immutability or a grace period.

The escapes, in order of preference

Escape	What it costs
Partition to a single writer	Partitionability; skew is the ceiling
Immutability	Space and a collector
Optimistic concurrency	Retries, at a rate of 1/(1 − ρ)
Coarse locking	Scalability; frequently the right answer for structures that are not hot

Case, resolvedConstructed case · Arjun at Parcelo

More threads, fewer events per second

Going from 8 to 32 ingest threads dropped throughput from 4.0 to 2.6 million events a second, with a shared counter and one shared queue as hot spots, and a query thread crashed daily after following a pointer into freed memory. Where it started: Concurrency-friendly structures →

Arjun applies the three escapes in order.

Do not share (partition). Events are routed by a hash of tracking_id to one of 32 shards. Each shard has one writer thread that owns its part of the index. Network threads hand events to the owning writer through an SPSC ring (one ring per network-thread/writer pair, so each ring still has one producer and one consumer). head and tail sit on separate cache lines. Ring depth comes from Little's Law: 150,000 events per second per shard × 10 ms of allowed backlog = 1,500 slots, rounded up to 2,048.
The global counter. events_seen becomes one counter per thread, each padded to its own 64-byte line. A reader of the metric adds them up. Nothing is shared on the hot path. Throughput now rises with threads, and the 32-thread rate passes the 8-thread rate instead of falling below it.
Do not mutate. The lookup index that API queries read is a persistent structure. A writer publishes a new root with one CAS. Readers use whichever root they loaded, with no locks and no writes. A bonus: the report jobs can hold an old root and see a consistent view of "the index as of 02:00".
The crash. The index is written in a language without a garbage collector, and the writer freed a node that a reader still held. Arjun adds epoch-based reclamation: a retired node is freed only after every reader thread has moved past the epoch in which it was retired. He also adds an alarm on "oldest active epoch age", because one stuck query thread would block reclamation and make memory grow without bound. This is the same alarm the Parcelo database team already had on "oldest open transaction".
A lesson about hot paths. The small admin map (list of depot codes, a few hundred entries, updated rarely) keeps a plain mutex. It is not hot, an uncontended lock costs about 20 ns, and Lena says: "Coarse locking is allowed where the structure is cold."