record writes took one of 256 mutexes picked by the first byte of the trimmed did, so a backfill holding its repo's lock for the whole persist (p50 30 ms, p99 1.35 s, max 2.4 s in the lock census) also blocked every unrelated repo on that stripe. the relay takes that lock first for each live commit and works one message at a time, so one collision stalled a whole relay shard, and a multi-repo call like track took most of the stripes at once. the locks now live in a sharded map from repo key to a parking_lot mutex. an entry is made when a repo is first locked and removed when its last holder or waiter lets go, and a shard that a big lock set grew gives its room back once it's mostly empty, so the table stays the size of what's being written right now. multi-repo txns (track, untrack, resync) still take their locks sorted, now by repo key, and assert that set is their first lock. the crawler still commits a page as up to 256 txns, grouped by a hash of the did, each taking its group's locks in order, so waiting on one busy repo holds a few others at most. in the lock census (1000 live commits/s plus 32 backfills at 60 MB/s on this mac, with a scratch prototype of the same per-did locking) live p99 went from 695-821 ms to 260-312 ms, p99.9 from 1.2-1.6 s to 437-532 ms, and relay waits on a repo lock from 800-900 to 1-5 per 150 s run. 8192 stripes measured the same tail, but a long redaction or a big track call would still block every repo sharing its stripes. keying the map by shard instead of repo times out other_repos_dont_wait and a_big_lock_set_gives_its_room_back on the deadlock and fails a_waiter_keeps_the_entry_until_it_is_done. removing the entry on every drop fails the waiter and big set tests, never removing it fails all three, handing out a guard without locking fails one_repo_waits_for_its_holder, keying the txn's locks by the old stripe bytes fails repos_that_shared_a_stripe_dont_wait_on_each_other, and dropping the shrink fails a_big_lock_set_gives_its_room_back.