Mechanical Sympathy: Concurrency, Queueing Laws & Integrity

• Compare-and-swap — atomically: if (*addr == expected) { *addr = new; return true } else return false — one CPU instruction, and the entire foundation of lock-free programming: read, compute, CAS, retry on failure. Java surfaces it as AtomicLong/AtomicReference, VarHandle.compareAndSet, and inside ConcurrentHashMap, lock striping, and the JVM's own biased-lock machinery.
• You've been using CAS at every scale all course: Redis SET NX (M19's lock acquire) is CAS on a key; SQL UPDATE ... WHERE version = ? (M16's guard) is CAS on a row; Raft's vote-once-per-term (M30) is CAS on a ballot. The pattern — optimistic attempt, atomic verify, retry — is scale-invariant; only the latency of the attempt changes (25 ns → 0.5 ms → quorum RTT).
• ABA — the classic trap: value went A→B→A between your read and your CAS; the CAS succeeds but the world it validated is gone (a freed-and-reallocated node in a lock-free stack; at system scale: a lock released and re-acquired — the M19 stale-holder in miniature). Fix is identical at every scale: pair the value with a monotonic version/stamp (AtomicStampedReference; the row's version column; the fencing token). M32 named this trick "logical clocks"; here it is at nanosecond scope.
• Contention economics: under heavy contention CAS loops burn CPU retrying (and cache-line ping-pong between cores dominates — false sharing puts unrelated hot fields on one line and makes strangers contend). The high-throughput fix is reducing sharing, not smarter sharing: LongAdder beats AtomicLong for hot counters by striping across cells and summing on read — which is M05's partitioning strategy, applied to eight bytes.

• The staff-level framing of Loom: it removes the concurrency ceiling reason for reactive code — you keep debuggable, blocking-style Spring MVC and stop losing a pool slot per in-flight downstream call (the very coupling that made M12 slow-call amplification so vicious). It does not remove event loops' place at the extreme edge (per-connection memory at 500k SSE connections still matters), doesn't speed up CPU-bound work, and imports one new failure mode: pinning — a virtual thread blocking inside synchronized or native calls pins its carrier OS thread; audit hot paths for synchronized-around-IO (older JDBC pools and legacy libs are the usual suspects) before migrating.
• What survives the migration unchanged: bulkheads and admission control (M13/M14) — "unlimited cheap threads" means the thread stops being the natural limiter, so without explicit semaphores/limits your service will now happily accept work far past what downstreams and its own CPU can bear (Little's Law, next section, tells you exactly how far). Loom changes the cost of concurrency, not the need to bound it.
• Sizing rule for classic pools while you still have them: IO-bound ≈ cores × (1 + wait/service time); CPU-bound ≈ cores. Both are corollaries of the next section's first law.

Little's Law: L = λ × W — in-flight work = arrival rate × time-in-system. No assumptions, no distribution fine print; it's conservation. It was silently under M13 (pool size must cover λ×W or the queue grows), M12 (a timeout stretch multiplies W, thus L — why slow is worse than down), M02 (throughput ceilings), and M25 (pods = λ×W ÷ per-pod concurrency). USL adds what happens when you scale out: C(N) = N / (1 + α(N−1) + βN(N−1)) — α is contention (the serialized fraction: locks, single writers, one hot partition), β is coherence (crosstalk: cache invalidation, consensus rounds, gossip — everyone syncing with everyone). α caps your speedup (Amdahl); β makes throughput decrease past a peak N — retrograde scaling, where adding nodes makes it slower.

• Reading the bars: amber = peak useful cluster size; red = retrograde territory where node N+1 subtracts throughput. Set β to 0 and watch the curve flatten toward Amdahl's ceiling (1/α) but never fall; any β > 0 guarantees a peak. Then recognize your systems: a hot partition (M05) is α; consensus on the write path (M30's warning) is β; cache-invalidation chatter and full-mesh gossip are β — and "we added nodes and it got slower" stops being a mystery and becomes a measurement of β.
• Little's Law as the red-flag detector (use in every review): proposed λ × expected W = required concurrency — compare against pool sizes, connection limits, per-pod capacity. 2,000 rps × 1.5 s tail = 3,000 in-flight: if the fleet holds 800 slots, the design collapses at the whiteboard instead of at kickoff. Same math sizes M14's shed point and explains M12's amplification arithmetic in one line.

• Silent corruption happens at scale — bit rot, controller bugs, cosmic-ray flips, buggy NICs. At hundreds of services × petabytes of segments, "rare" multiplies into "weekly." And note what your redundancy does about it: nothing — replication (M04) faithfully copies corrupt bytes, and backups retain them. Detection must be explicit: checksum at rest (per block/object — ZFS, S3 ETags, Kafka per-record CRCs), in flight (per message), and verify on read — a mismatch triggers read-from-replica + repair, turning corruption from wrong-answers into a handled fault class.
• Scrubbing: a background pass re-reading cold data, verifying checksums, and repairing from good replicas — because unread data rots invisibly until the day all copies have independently rotted. ZFS scrubs, S3 does it internally, HDFS block scanners — and your own long-retention stores (the content archive, the event lake) need an answer to "who re-reads this, ever?" (It's also M04's anti-entropy with a checksum instead of a vector — same epidemic repair idea.)
• The end-to-end argument (Saltzer/Reed/Clark, the most cited principle in systems): reliability features in lower layers are optimizations only — TCP checksums, disk ECC, and TLS integrity each cover their hop, but nothing below the application can catch corruption that happens between layers (in your process memory, during transcode, in a buggy serializer). Only an application-level check spanning source to destination actually verifies the thing you care about: checksum the segment at packaging, verify after the CDN hop; checksum before compression, verify after decompression. This is also why M16 put idempotency at the application layer and M24 measured at the edge — the end-to-end argument is the same reasoning applied to delivery and to observability.
• CRC vs MAC (the M20 boundary): checksums/CRCs detect accidents and are trivially forgeable; against adversaries you need MACs/signatures (M20). Same field in the packet, different threat models — don't let a design review conflate them.

Fast trackStep 2 (~30 min): the Loom pinning audit is the one with immediate production value for your estate.

Self-check