You've weighted your nodes by capacity. You've bounded loads to prevent hot shards. You've added adaptive rebalancing so capacity changes at runtime don't require a redeploy. Now you hit the next failure mode: when a shard overflows, where does the excess go? Naive bounded-load implementations just walk the ranked list and hand the key to the next node. That node might already be at 99% of its own bound. Congratulations — you've just cascaded the overflow.

Capacity-aware overflow fixes this by making the fallback decision itself respect the load bounds of every candidate, not just the primary. When node A is full, you don't take the next node in rendezvous order blindly — you take the next node that has headroom relative to its own weighted capacity.

The algorithm:

• Compute weighted rendezvous scores for the key across all nodes.
• Sort candidates by score descending.
• Walk the list: accept the first node where current_load / weighted_capacity < overflow_threshold (typically 1.25).
• If no node qualifies, either reject the write (backpressure) or raise the threshold globally and alert — never silently overload.

Real-world example: A video-transcoding job queue shards tasks across a fleet with mixed hardware: 8 GPU nodes at weight 4, 24 CPU nodes at weight 1. During a viral upload spike, GPU node G3 hits its bound. Naive overflow picks G4 (next in rendezvous order), which is also at 98%. G4 tips over, cascade continues. Capacity-aware overflow instead skips G4, checks the next ranked node, finds CPU node C17 at 40% of its (smaller) bound, and places the job there. Slower transcode, but the fleet stays healthy.

Rule of thumb: Set your overflow threshold at 1.25× weighted capacity and your rejection threshold at 1.5×. If more than 5% of writes traverse more than 3 candidates before placement, your fleet is under-provisioned — add capacity, don't raise the threshold.

What to watch for:

• Rendezvous cost: walking many candidates per key is O(N) per placement. For fleets over ~500 nodes, precompute a top-K candidate list per key and refresh it on membership change.
• Placement stability: capacity-aware overflow can move keys when a downstream node fills up. Emit a metric for "keys placed off-primary" — a rising trend means your weights are wrong, not that overflow is working.
• Feedback loops: if overflow decisions feed back into the load metric before the write completes, you'll oscillate. Use a short EWMA (5–10s) on load, not instantaneous counters.