id: design: spill v2 — native spill pools, lease failover and multi-holder fencing (extends #2819) #5787

Summary

Design spill v2: what happens after the single-spill-node write lease — a pool of native spill nodes for a hot world, lease arbitration among them, and lease behaviour under partition between the Durable Object and multiple native holders.

Motivation

#2819 designed the write lease for exactly one spill target: when a world gets too hot for its hosted DO, execution spills to a native id node, and the journaled single-writer lease (DO as sole grantor, epoch fencing on append, journaled handoff) decides who may write. That design is landed as a protocol (design doc doc/2026-11-01_design_id2819.md; phases #3803–#3805). Its scope is honestly singular — one holder at a time, one spill node. The obvious next step it doesn't take: a world hot enough to spill may be hot enough to need more than one native node — read replicas are easy (the journal is the record), but write scaling, failover when the spill holder dies mid-term, and a second spill while the first is still draining are all undesigned. If that day comes with no design, the lease gets stretched by improvisation in exactly the place #2819 said catastrophe lives: "split-brain (DO and native node both accepting writes) is the catastrophic failure."

Sketch

• Holder failover: lease term expiry and revocation when a holder dies or partitions — who detects it, what the DO may assume, and the in-flight command posture (extending v1's retryable not-holder rule) when the holder vanishes mid-term rather than handing off politely.
• Spill pool: multiple native nodes eligible for one world — grantor selection policy, whether epochs stay per-world global (recommended by v1's shape) or partition, and how a second node joins as reader-then-holder.
• Read-your-spill: native read replicas under a held lease — staleness bounds, and whether a replica may serve presence/session traffic.
• Multi-world spill: one native node spilling many worlds — per-world leases composing on one host, resource fairness between spilled worlds (composes with design(id): DoS suite & performance benchmark programme — adversarial CI coverage and per-interface regression gates #5685's fairness-attack cases).
• Region interplay: spill across regions vs id: design: region-seam handoff format — journaled export/import for hot-world region shards (from #2059) #2818's region-seam handoff — when is a hot world spilled, when is it moved?

Open questions

• Is write scaling ever actually needed, or does the honest v2 stop at failover + read replicas? The design should say, with the load argument.
• Lease term/renewal defaults (v1: 30 s / 10 s) under failover — shorter terms trade journal traffic for recovery time; what's the evidence?
• Does the epoch stay a single monotonic counter when holders change across nodes with skewed clocks — v1 says the journal position is the truth; does that survive?

Relations

Parent: epic #2056. Extends: #2819 (v1 lease — design landed, implementation phasing in #3804/#3805). Relations: #2818 (region-seam handoff), #2059 (hot worlds), #5685 (fairness cases), and the deterministic-testing design (lease fencing is one of its named oracle properties — failover interleavings are its test case). Filed in the 2026-11-04 gap pass (WS-F) as a version-ladder design: design now, implementation when load demands it.