Designing Graceful Degradation for Routing Failures

Graceful degradation is the discipline that keeps an indoor navigation session alive when the routing graph, the network, or the positioning fix fails, and it is the operational core of the Fallback Routing Architectures reference: instead of one routing call that either works or throws, you build a ladder of progressively weaker but always-safe tiers, each guarded by a health check, that a resolver walks until one answers.

What “Graceful Degradation” and “Fail-Closed” Mean #

Graceful degradation means a system that loses capability in defined steps rather than collapsing all at once. For an indoor router, the fullest capability is a fresh, live routing graph reflecting real-time closures; the weakest usable capability is a static, pre-baked emergency-egress map showing only the exits. Between them sit intermediate tiers — a last-known-good cached graph, for instance. Each tier is strictly less capable than the one above it and strictly more likely to be available, and the resolver’s job is to serve the highest tier that currently passes its health check.

“Fail-closed” is the rule that decides what happens when every tier a user might want is unavailable. A fail-open system, faced with a missing graph, returns something anyway — a blank canvas, a straight line through walls, a stale route that ignores a live closure — and that is worse than useless because it looks authoritative while being wrong. A fail-closed system refuses to invent an answer: it degrades to the most conservative safe state it can still vouch for (the emergency-egress layer, and past that an explicit “routing unavailable”), and it never presents guidance it cannot stand behind. In a building, a confident wrong turn can walk someone toward a hazard, so fail-closed is not a preference here — it is a safety property.

Minimal Working Example #

The resolver below walks a tier ladder from the live graph down to a safe “unavailable” state. Each tier pairs a loader with a health check; the resolver serves the first tier whose health check passes and whose loader returns a graph, logging which tier it served so degradation is observable. Nothing throws to the caller — the terminal tier is always a valid, if minimal, response.

import logging
from dataclasses import dataclass
from typing import Callable, Optional

logging.basicConfig(level=logging.INFO, format="%(asctime)s | %(levelname)s | %(message)s")
logger = logging.getLogger(__name__)

RoutingGraph = dict          # opaque graph payload for this example
Loader = Callable[[], Optional[RoutingGraph]]
HealthCheck = Callable[[], bool]


@dataclass(frozen=True)
class Tier:
    name: str
    load: Loader             # returns a graph or None
    healthy: HealthCheck     # cheap signal: is this tier usable right now?


def resolve_graph(ladder: list[Tier]) -> tuple[str, RoutingGraph]:
    """Serve the highest healthy tier; fail closed to a safe state, never raise to the caller."""
    for tier in ladder:
        try:
            if not tier.healthy():
                logger.warning("tier '%s' failed health check, descending", tier.name)
                continue
            graph = tier.load()
        except (OSError, TimeoutError) as exc:
            logger.warning("tier '%s' load error: %s, descending", tier.name, exc)
            continue
        if graph is not None:
            logger.info("served routing graph from tier '%s'", tier.name)
            return tier.name, graph
    # Terminal, fail-closed state: always available, always safe, never a lie.
    logger.error("all tiers exhausted; serving emergency-egress-only safe state")
    return "unavailable", {"mode": "egress_only", "edges": []}


LADDER = [
    Tier("live",      load_live_graph,      lambda: cdn_reachable() and fix_confident()),
    Tier("cache",     load_last_known_good, lambda: cache_fresh_within(minutes=30)),
    Tier("egress",    load_static_egress,   lambda: True),   # pre-baked, always healthy
]

served_tier, graph = resolve_graph(LADDER)

The ordering is the design. live is tried first because it is the most capable, but its health check is the strictest — it requires both a reachable CDN and a confident positioning fix. cache requires only that the last-known-good graph is recent enough. egress is always healthy because it is a static asset baked into the client, so the ladder can never fall through it — and only past it does the resolver reach the explicit "unavailable" safe state. No tier throws to the caller; the worst case is a minimal but honest response.

Degradation Ladder Reference #

Common Errors & Fixes #

Failing open — a blank canvas or an invented route. The resolver caught an exception and returned None or an empty graph straight to the renderer, which drew nothing or a straight line through walls. That is a confident lie. Ensure the ladder always terminates in a real, safe payload and that the caller treats the served-tier name as load-bearing, not decorative:

served, graph = resolve_graph(LADDER)
if served == "unavailable":
    ui.show_egress_only_banner()      # honest: "live routing is down, exits shown"
# never: if graph is None: render_blank()  -> that is failing open

No health check, so a dead tier is served anyway. Omitting tier.healthy() and relying only on the loader throwing means a tier that returns a stale graph without error is served as if fresh — a cached route that ignores a live corridor closure. Gate every tier on an explicit, cheap health signal (CDN reachability, cache age, positioning confidence) so an unhealthy-but-not-erroring tier is skipped before its loader ever runs.

Unbounded retry blocking the descent. A loader that retries a hung network fetch forever never lets the resolver fall to the next tier, so the user stares at a spinner instead of getting the cached graph. Bound every loader with a timeout and treat the timeout as “descend”, never “retry in place”:

# WRONG: retry loop with no ceiling blocks the whole ladder.
# while True: g = fetch();  ...
# RIGHT: one bounded attempt; a timeout descends to the next tier.
graph = fetch_with_timeout(seconds=1.5)   # raises TimeoutError -> resolver descends

Integration Point #

This resolver is the mechanism behind the tiered state machine described in Fallback Routing Architectures — that section frames the policy (which tiers exist and why each loosens its guarantee), and this reference supplies the engine (a health-gated ladder walk that fails closed). Downstream, the same fail-closed ladder is what a client consumes: the SDK Integration Patterns degradation contract descends from the latest synced graph to a last-known-good cache to a pre-baked emergency-egress layer using exactly this structure, so the server-side resolver and the on-device ladder share one shape. Whichever graph library serves the live tier — the trade-off weighed in NetworkX vs. igraph for large routing graphs — the degradation ladder wraps it unchanged, because the ladder cares about tier health, not the container underneath.

Frequently Asked Questions #

Related #

• Fallback Routing Architectures — the tiered state machine whose policy this resolver implements.
• SDK Integration Patterns for Indoor Maps — the on-device degradation ladder that consumes this same fail-closed structure.
• NetworkX vs. igraph for Large Indoor Routing Graphs — the graph library that serves the live tier this ladder wraps.

This page is part of the Fallback Routing Architectures guide within the Indoor Mapping Architecture & Standards reference.