[sorenbs]

Stacked on #143. A fleet member that owns more than its fair share of shards moves one, per move cooldown, to a member below the share, until every member is within it.

Why

The ring's rendezvous hash uses FNV-1a over "<shard> streams-<n>". Member names that differ in one digit score in step, so the spread is uneven:

• 64 shards over 4 members: 17 / 11 / 8 / 28 measured, 17 / 10 / 7 / 30 from the hash.
• 64 shards over 8 members: one member still held 28 measured, 33 from the hash.

The rebalancer moved shards only for lag, and a healthy fleet has none, so nothing evened out: one member kept 28 shards for 8 minutes. A platform that balances pinned requests evenly is then capped by that member, which carried about 44% of the load.

What changes

src/fleet/count_balance.rs, called from the fleet tick when this instance is not lagging and its move cooldown has passed.

• When it moves: an instance that owns more than ceil(shards / members) writes the same override, retirement and eager handoff that a lag move uses.
• What it moves: one of its own shards with no override, preferring one whose rendezvous home is the target, so a count move never undoes a lag move.
• Where it moves: to a member below the share that is not lagging.
• No pile-ups: instances past the share take different targets at the same tick, each by its rank by name.
• No flapping: return-home already admits a return only within the same share, so the two passes don't undo each other.

Measured

On Habanero's services bench, with REBALANCE_MOVE_COOLDOWN_SECS=5:

• Spread: 32/32 within 50 s, 16 each within 85 s, and 8 each within about 4 minutes.
• Throughput: 1, 2 and 4 instances then served 3,698, 7,774 and 15,262 pinned appends a second through the edge. That is 105% and 103% of linear.

Return-home and count placements (second commit)

Return-home dropped a count move's override 300 s after the move, which put the shard back on its crowded ring owner. The count pass then moved it again, without end. The Overrides document now keeps the prefixes a count move placed, in counted:

• return-home leaves those prefixes alone;
• a later count move may move them again;
• a return-home drop removes the prefix from the set.

A document written before the field has none, so nothing changes for it. fleet::overrides holds the types now, since fleet.rs had reached its line ceiling. TLA-011 was re-recorded for it.

Records

• Edge change #236.
• #235's known window is corrected: a non-owner answers 404 for 4 to 8 s after a create even when the create went straight to the owner.
• docs/SCALING.md.
• The fleet_count_balance mutation owner, and re-measured sizes.
• Exception-growth rows for fleet::start, which the owner approved on 2026-10-31.

Tests

• Red: with the pass disabled, moves_bring_every_member_within_the_fair_share failed with 2 members: 33.
• Green: the four fleet::count_balance tests pass, and so does dst_tests::fleet_controller. That suite caught a first version that moved an overridden shard straight back; the no-override rule fixes it.
• Gate: scripts/gate.sh reached GATEDONE, and the release suite had 2,328 passed and 0 failed.

Breaking change

A healthy fleet now moves shards after a start or a change of membership. A pinned client sees its stream's owner change once for each moved shard, and follows Streams-Forwarded-To or Streams-Replay-To.

🤖 Generated with Claude Code

[sorenbs]

Landed on slate as part of the integration stack ending at 5660231 (gated locally; CI round 5 on PR #143's branch passed every mutant shard). #143's forwarding is edge #235, ratified by the owner on 2026-11-01. #144 was reworked as its own task beside fleet::start (edge #236). #145 carries an added retry after a failed inherited seal. The commits are on slate; closing without a GitHub merge, per the repository's slate-direct workflow.

🤖 Generated with Claude Code