USE CASES

Three ways an Anchor gets deployed. Pick the one that looks like your network.

The sizing rule never changes — Cores where paths terminate, Edges everywhere they originate — but where the Anchor actually sits depends on whether you own the network in the middle or only the edge. These are the three deployment topologies we build against, not hypothetical diagrams.

anchor_relationship: monitors-the-network

Telecom / ISP — full mesh, PoP to PoP

Anchors sit inside infrastructure the ISP already operates — PE and P routers at each Point of Presence. Every PoP is a Core Anchor, terminating bidirectional measurement to every other PoP in the mesh. There's no edge/core split here: at carrier scale, every node is a hub.

anchor_relationship: monitors-from-the-edge

eCommerce · Quick Commerce · Retail — hub-and-spoke

Anchors sit at edge sites the customer owns — dark stores, retail locations, regional storefronts — each watching its own path out to a shared backend. The Core Anchor sits once, at the central DC or Cloud VPC, in front of the systems every edge site actually depends on: OMS, POS/ERP, payment gateway, checkout API.

anchor_relationship: hybrid

Enterprise — Core↔Core plus Edge→Core, combined

Enterprises both own their DC/Cloud interconnect and rely on branch connectivity they don't fully control. This deployment is the previous two combined: a Core↔Core hybrid-cloud WAN path between the HQ data center and its Cloud VPC(s), plus Edge Anchors at every branch office reporting toward those Cores.