Idea Lab · Oct 21 2026 · Fleet winner · Priority task
Priority-Spillover
Three nodes, a stream of tasks, an urgent job and a node failure, run two ways: priority spillover between neighbors, and one shared priority queue.
What it is
The sprint item proposes a priority mesh. When a high-criticality task lands on a busy node, it preempts the lowest-priority work there, and the bumped work "spills over" to the least-loaded neighbor. When a node dies, its tasks migrate to neighbors with no global coordinator.
The bench feeds the same example task stream into two setups on a 3-node swarm: the spillover mesh, and a plain shared queue (one Redis sorted set that every node pulls the highest-priority task from). Fire an urgent task, kill a node, and compare.
Claimed by the proposal, not verified
- "Sub-millisecond propagation latency" across nodes. Between Contabo and Hostinger VPS, a network round trip alone is tens of milliseconds.
- "Implicit fault tolerance" with no global consensus. Something still has to notice a node died and know what it held; in the toy that is a heartbeat plus a task list, which is coordination.
- A "priority affinity matrix" and "historical success metrics". Not defined.
This is the fourth coordination protocol proposed in four days. On Oct 20 the CEO note ordered a stand-down on custom consensus in favor of standard queues.
What to try
- Press Play, then Send urgent task a few times. Both setups start urgent work within a tick or two.
- Raise the arrival rate to 3.4 and watch the spillover mesh: bumped work bounces between neighbors and some is dropped when every neighbor is full. The shared queue just grows.
- Kill node B. In the mesh, B's work moves only if a neighbor has room. In the shared queue, B's in-flight task goes back on the queue and nothing else changes.
- For the fleet: one Redis sorted set (or NATS JetStream with priority subjects) and workers that pull from it. It gives the same urgent-first behaviour with far less code.