Skip to content

Alternate Pathway Routing

Rerouting workflow — instantiates Saturation Avoidance

Diverts incoming demand to a different channel or handler when the primary one saturates, while watching the fallback so the problem isn't just moved.

When a channel is saturated, one option is to stop adding to it — not by refusing demand outright, but by sending it somewhere that can still respond. Alternate Pathway Routing is the workflow that gives demand another door: a second team, a self-service path, an asynchronous handler, a different region, when the primary channel is past its useful limit. Its defining move — and the reason it is a distinct mechanism — is the pairing of a switch trigger (a rule for when to divert) with a secondary check (watching whether the destination is itself absorbing the load or just tipping over next). Rerouting without that check doesn't avoid saturation; it relocates it. Note the boundary: this diverts within the channel family to protect the primary; deciding the whole approach has plateaued and should be abandoned belongs to the neighbouring pattern of plateau detection and switching.

Example

A content platform serves images through a network of edge locations. One regional edge (call it the São Paulo PoP) starts to saturate during a viral event — cache-fill latency climbs, its origin link is nearly full. Alternate Pathway Routing has a switch trigger wired to that signal: when the PoP crosses its saturation threshold, a defined share of requests fails over to the next-nearest healthy edge and, for cacheable content, to a static fallback. Users see marginally higher latency instead of errors, and the primary edge gets room to recover.

The workflow's real intelligence is the secondary check. It watches the receiving edge as the diverted traffic lands — because a naïve failover can push a healthy PoP straight into the same saturation, and if that one fails over too, the diversions chain into a cascade that takes down more capacity than the original event.[1] When the secondary check sees the fallback approaching its own limit, routing throttles the diversion rather than continuing to shove load down a filling path.

How it works

  • Define the fire condition. A switch trigger tied to the primary channel's saturation signal decides when diversion starts and how much — not a manual scramble mid-incident.
  • Provision a real alternate. The fallback must be able to actually respond (own capacity, acceptable quality), not merely accept intake; a dead-end path is worse than a queue.
  • Meter the diversion. Move a controlled share, adjustable as conditions change, rather than an all-or-nothing flip.
  • Watch the destination. The secondary check monitors the fallback for its own saturation and pulls back before rerouting simply relocates the failure.

Tuning parameters

  • Trigger threshold — how saturated the primary must be before diversion begins. Early diversion protects the primary but spends the fallback's capacity sooner; late diversion risks the primary tipping first.
  • Diversion share — what fraction of demand reroutes. Higher relieves the primary faster and loads the fallback harder.
  • Fallback quality floor — the minimum acceptable response on the alternate path. A high floor keeps only genuinely capable alternates; a low one accepts degraded handling to avoid outright failure.
  • Secondary pull-back point — how close the fallback may get to its own limit before diversion is throttled. Governs whether the workflow protects the destination or sacrifices it.

When it helps, and when it misleads

Its strength is giving demand somewhere real to go, so a saturated primary neither drops work nor collapses — and its secondary check is precisely what separates genuine relief from moving the fire to the next room. It shines where capable alternate capacity exists and can be metered.

Its failure modes cluster around the fallback. Routing to a path that can accept but can't respond converts a saturated channel into a slower saturated channel; routing without the secondary check invites cascading failure as each overloaded destination fails over into the next; and a reroute quietly left permanent lets the primary's real capacity problem hide behind a fallback now carrying baseline load it was never sized for. The discipline is to verify the alternate can actually respond, keep the secondary check live, and treat sustained diversion as a signal to fix or expand the primary rather than as a resting state.

How it implements the components

Alternate Pathway Routing fills the archetype's divert-and-monitor components:

  • alternate_pathway — it provisions and operates the second channel demand is sent to when the primary is saturated.
  • switch_or_reroute_trigger — it owns the rule for when to stop adding to the primary and start diverting.
  • secondary_saturation_check — it monitors the destination so the reroute relieves rather than relocates.

It does not reduce input at the source — capping is Frequency Cap's and gating is Queue Admission Limit's — nor does it grow the primary channel; that is Capacity Expansion Trigger's. It moves demand sideways, not down or up.

  • Instantiates: Saturation Avoidance — protects a saturated channel by diverting demand to a monitored alternate.
  • Sibling mechanisms: Overflow Queue · Saturation Dashboard · Capacity Expansion Trigger · Queue Admission Limit · Frequency Cap · Channel Capacity Management · Graceful Degradation Mode · Attention Cap Management · Worker Caseload Limit · Ad Frequency Cap

Notes

Routing (send demand elsewhere) and Overflow Queue (hold demand in place and serve it later) are the two "somewhere to go" answers and are easily confused. Reach for routing when a capable alternate handler exists now; reach for the overflow queue when the right response is to delay, not divert. They compose: divert what a fallback can serve, queue what must wait.

References

[1] A cascading failure occurs when load shed from one saturated component overwhelms the next, which fails over in turn — the mode distributed systems guard against with load-aware failover and back-pressure. It is the concrete risk that makes the secondary-saturation check non-optional.