Routing Rule¶
Protocol — instantiates Local Rule Design
Implements local rule design by specifying how each node, queue, dispatcher, or participant decides where work, traffic, requests, or attention should go next.
A routing rule makes one narrow local decision — where should this unit of work go next — using only locally-visible load, so that a system-wide flow pattern (balanced queues, coverage, reachability) emerges from many independent next-hop choices. What makes it this mechanism is the pairing of a next-destination decision with a macro flow goal and an intrinsic watch for its own signature pathology: because every actor reads the same load signal, identical local choices can synchronize into oscillation. A routing rule is therefore always half a decision rule and half a monitor of the aggregate it produces. It assumes the handoff can happen and only chooses the destination; it does not price the work or verify that two components can technically interoperate.
Example¶
A busy emergency department must send arriving patients to one of several treatment zones without a central controller assigning each case. The routing rule: each triage nurse sends the next non-critical patient to the zone with the shortest current queue shown on a status board. It works — until it doesn't. Whenever one zone momentarily empties, every nurse routes the next several patients there at once, swamping it while the others sit idle, then the swing reverses. The flow oscillates. The department damps it: route on a short moving average of queue length rather than the instant value, add a small random tiebreak so nurses don't all pick the same zone, and cap each zone's intake rate. The oscillation smooths into steady, balanced flow — the macro-pattern the rule was aimed at, held stable by watching for the herd and breaking it.
How it works¶
- Local next-hop decision. Each dispatcher chooses a destination from the load it can see right now — the local rule.
- Load is the feedback. Queue length, congestion, or wait time is the signal the decision reads.
- Aim at a flow goal. Balanced queues, minimized wait, full coverage — an explicit aggregate target the choices serve.
- Watch the aggregate for oscillation. Monitoring for flapping and herding is not optional; it is how the rule is kept from destroying its own goal.[n1]
- Damp the herd. Averaged or stale signals, hysteresis, and randomized tie-breaks desynchronize identical local choices.
Tuning parameters¶
- Signal freshness — instantaneous load versus a moving average. Fresh is responsive but oscillation-prone; averaged is stable but lags real congestion.
- Greediness — strict shortest-queue versus sampling a couple of options ("power of two choices"). Strict is optimal in isolation but herds; sampling is nearly as good and far more stable.
- Damping / hysteresis — how much a destination must improve before work switches to it, trading responsiveness against thrash.
- Tie-break randomization — how much noise breaks ties, spreading load at a small cost in per-item optimality.
- Look-ahead — myopic next-hop versus path-aware routing, trading simplicity against foresight about downstream congestion.
When it helps, and when it misleads¶
Its strength is real-time load adaptation with no central dispatcher and no single point of failure — each node reacts to what it sees, and the aggregate flow follows.
Its failure mode is oscillation and route flapping: identical rules reacting to one shared signal synchronize into swings that are worse than no balancing at all.[n1] The cousin failure is local greed producing global congestion — everyone takes the "shortest" path until it becomes the longest. The classic misuse is routing on instantaneous load with no damping, which practically guarantees the herd. The guarding discipline is to feed the decision slightly stale or averaged signals, add randomization and hysteresis, and keep watching the aggregate for flapping so the rule can be retuned before the swings set in.
How it implements the components¶
local_rule— the per-item next-destination decision each node makes.feedback_signal— the locally-visible load, queue, or congestion reading the decision consumes.emergent_pattern_monitor— watching aggregate flow for oscillation, flapping, and imbalance is intrinsic to keeping the rule healthy.macro_pattern_goal— the target aggregate: balanced queues, coverage, or minimized wait.
A routing rule does not implement boundary_condition (message validation and compatibility) or exception_or_escalation_rule (retry and handshake recovery on a failed exchange) — it assumes each unit *can be handed off and only chooses where; establishing that two components can correctly exchange at all is Protocol Rule. A routing rule decides where work goes; a protocol rule decides how components talk.*
Related¶
- Instantiates: Local Rule Design — a routing rule is the flow-shaping instance of producing a system-wide pattern from local next-hop choices.
- Sibling mechanisms: Swarm Rule · Cellular Automata Rule · Market Rule · Protocol Rule · Team Working Agreement · Community Norm · Decentralized Governance Norm
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Routing Rule operates by reads live local congestion and automatically selects the next hop that advances the flow goal. That concrete deployed or enacted form is Control, Automation & Runtime under the frozen taxonomy.
Nearest alternative: Rule, Policy & Commitment — Although Rule, Policy & Commitment can support this mechanism, the frozen evidence makes its operative form the act that reads live local congestion and automatically selects the next hop that advances the flow goal; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Local next-hop and dispatch rules are foundational networking and computing mechanisms.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: implements local rule design by specifying how each node, queue, dispatcher, or participant decides where work, traffic, requests, or attention should go next.
- Operations Research — Operations research, optimization, and queueing analysis supplies a parallel or contributing lineage for the mechanism's defining operation: implements local rule design by specifying how each node, queue, dispatcher, or participant decides where work, traffic, requests, or attention should go next.
- Organizational & Management Science — Workflow design independently routes cases and attention among participants.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement, encyclopedia_synthesis_disagreement starts from reviewer_a's mechanism-specific evidence: Local next-hop and dispatch rules are foundational networking and computing mechanisms. Reviewer A proposed alternates=operations_research, organizational_management, origin_mode=convergent, domain_reach=universal, and encyclopedia_synthesis=true; reviewer B proposed alternates=engineering_design, operations_research, origin_mode=convergent, domain_reach=universal, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (operations_research, organizational_management, engineering_design) without an arbitrary cap, selects origin_mode=convergent to represent the combined lineage evidence, and records domain_reach=universal and encyclopedia_synthesis=true. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Route flapping is the networking pathology where a route repeatedly and rapidly switches state, so devices spend their effort reacting to the churn rather than carrying traffic. It is the canonical example of local routing choices synchronizing into destabilizing oscillation, and the reason damping is a first-class routing dial. ↩a ↩b