3 Measuring Topologies with Graph Metrics

3.3 Overview: Topology Analysis Turns Diagrams Into Evidence

This section: Overview: Topology Analysis Turns Diagrams Into Evidence — A topology diagram is a useful sketch, but analysis asks what the sketch proves.

A topology diagram is a useful sketch, but analysis asks what the sketch proves. Model devices and links as a graph, measure the paths that traffic depends on, and test which nodes, links, gateways, channels, power sources, or ownership boundaries can break the service.

The goal is not to crown one topology name as good or bad. Star, tree, ring, mesh, bus, and hybrid patterns all work in the right conditions. A design is defensible when its metrics, failure behavior, and field evidence match the deployment constraints.

Consider a warehouse design where forty shelf sensors appear to form a healthy wireless layout because every sensor can reach a gateway during installation. The graph record may tell a different story: most routes still cross one relay aisle, the gateway has the highest degree, and the cold-room sensors have longer retry paths than the rest of the floor. A useful analysis records those dependencies before release. It asks which nodes become unreachable if the relay aisle loses power, whether alarms still arrive during a burst, and whether operations can see the difference between weak radio links, gateway queues, and application ingestion delays.

The warehouse sketch becomes defensible only when its nodes and links pass through a repeatable analysis. Figure 3.1 previews that route so each later metric and probe has a clear place in the final decision record.

+

The numbered path in Figure 3.1 begins with Inventory, recording nodes and links, then moves through Metrics such as degree, diameter, paths, and reach. Failure Zones exposes hubs, bridge links, gateways, and power dependencies before Scale Pressure and Routing Work add state, support, discovery, and repair costs. Evidence captures counters and traces, and Decision Record binds the assumptions, limits, evidence, and recheck triggers. That sequence turns the opening warehouse example from a tidy drawing into an inspectable claim about what remains reachable under stress.

Overview Knowledge Check

3.4 Practitioner: Build the Topology Analysis Record

This section: Practitioner: Build the Topology Analysis Record — A practical analysis should fit on one page.

A practical analysis should fit on one page. It names what the graph includes, the metrics that matter, the failure probe, the logs and counters to keep, and the site change that requires the decision to be checked again.

Counting links alone cannot reveal whether the remaining paths are useful. Compare degree, shortest path, diameter, bridge links, and weighted links to complete the one-page analysis.

See Figure 3.2 in the figure below.

+

Router R1 degree = 3 illustrates Node degree, while the highlighted route between sensors and the gateway, labelled GW, illustrates one Shortest path. Diameter is the longest shortest path, not simply the longest drawn edge. A Bridge link or relay can split the graph when it fails. Weighted links attach retry rate, latency, quality, or capacity to edges that would otherwise look equal. Connectivity shows whether a path exists; weights and failure probes show whether it is useful in operation.

Use formulas as first-pass checks, not as deployment truth. A full mesh with n nodes needs n(n - 1) / 2 links, while a partial mesh with average degree k has about n * k / 2 links. Those numbers reveal maintenance pressure, but the decision still needs weighted links and failure probes.

Practitioner Knowledge Check

3.5 Under the Hood: Failure Domains Decide Whether Metrics Matter

This section: Under the Hood: Failure Domains Decide Whether Metrics Matter — A topology can be connected and still be fragile.

A topology can be connected and still be fragile. A graph has an articulation node if removing one node separates reachable groups. It has a bridge link if removing one link partitions traffic. It has a shared dependency when apparently redundant paths rely on the same gateway, switch, channel, power circuit, certificate, cloud service, or operating team.

Routing overhead also grows through the graph. Neighbor discovery, route maintenance, acknowledgements, retries, state storage, convergence (settling on working routes after a change), and sleep behavior can make a theoretically resilient topology expensive or unstable in the field.

Pair failure tests with measured link weights. Removing a bridge link from an unweighted graph shows partition risk, but it does not show whether the alternate path is usable under battery, latency, duty-cycle, or interference constraints. A sleepy relay may be a valid backup for slow telemetry and a poor backup for command traffic. A redundant uplink may still share one power circuit or one operations team. Document the assumed failure, affected flows, measured or observed weights, degraded mode, and exact condition that requires another test.

Graph metrics matter only when they predict the service effect of a plausible loss. Compare familiar shapes by what fails together.

See Figure 3.3 in the figure below.

+

A star depends on its hub, and a tree on its parent branches; one shared role can isolate many leaves. A ring becomes a line after a break. A mesh needs an observed reroute before an alternate path can be treated as working. Local connectivity alone does not establish cloud service: check queues, uplink state, timing, and duplicates at the gateway. Describe which flow persists, which slows or buffers, and which still fails beyond a surviving local graph.

Keep the failure-test results together with the conditions they cover. Include assumptions, graph metrics, removed dependencies, operating measurements, limits, and changes that require another check.

See Figure 3.4 in the figure below.

+

State the scope, environment, roles, and traffic assumed. Keep degree, paths, diameter, connectivity, and weak links alongside the hub, router, link, gateway, channel, or power source removed during each test. Add neighbour tables, traces, logs, counters, and timestamps. State limits so the observations are not treated as universal. Reconsider an accepted or constrained topology choice when placement, load, responsibilities, or firmware changes.

Under-the-Hood Knowledge Check