Architecture

Latency runs on a multi-homed, cell-based network spread across the planet. No single provider, region, or machine is load-bearing. The system is built so that the thing watching for outages doesn't have outages of its own.

We deliberately mix cloud, bare metal, colocation, and the occasional VPS. Any one of them can disappear without taking the platform with it, and probing your services from genuinely independent networks is the whole point: a monitor that shares fate with the thing it monitors isn't worth much.

Cells

The unit of deployment is a cell: a self-contained cluster in one location that can run checks, evaluate rules, and raise alerts entirely on its own. A cell holds everything it needs: probe workers, the rules engine, local state, and a NATS node.

Cells are independent by design. If a cell is cut off from the rest of the world, it keeps checking the targets in its region and keeps its alerting working. It degrades to "local only" rather than going dark. When connectivity returns, it re-syncs. This is what "cell-based" buys us: the blast radius of any failure is one cell, never the platform.

New regions are added by standing up another cell, not by scaling a central system. Capacity and geographic coverage grow the same way, one cell at a time.

Independent cells across the planet, meshed as NATS leaf nodes into one super-cluster.

The NATS mesh

Cells are stitched together by NATS, a lightweight messaging system, arranged as a super-cluster of leaf nodes. Three ideas do the heavy lifting:

• Leaf nodes. Each cell runs a NATS server that connects outward to the core super-cluster as a leaf node. The cell never needs an inbound port open to the world, and it holds its own subject space locally. A probe VPS in another country participates in the mesh without us trusting it with anything more than the messages it's meant to see.
• Subject-based routing. Work and events flow over hierarchical subjects, not point-to-point connections. A check job published to worker.<region> is picked up by a worker in that region; results and incidents (incident.opened, incident.closed) flow back over their own subjects. Nothing needs to know where the other side physically is; the mesh routes by subject.
• Queue groups. Multiple workers subscribe to the same subject as a queue group, so a job is delivered to exactly one of them. That's how a cell load-balances checks across its workers, and how the platform survives a worker (or a whole cell) dropping out: the remaining subscribers simply pick up the slack.

Because the mesh is subject-addressed and leaf-connected, adding a cell is almost free: it dials into the super-cluster, announces the subjects it serves, and starts pulling work. No central registry to update, no routing table to hand-edit.

Durable streams (via NATS JetStream) carry the things that must not be lost (billing events, scheduled work) while transient checks flow over plain subjects. State that needs to be shared, like short-lived caches and the platform control plane, rides a replicated NATS key–value store so every cell sees the same view within seconds.

Compute

Applications run on virtualized or bare-metal servers depending on load and availability. Untrusted workloads, including user-defined functions, are isolated with gVisor, and everything is subject to aggressive, continuous security scanning.

Security

Every endpoint connected to our platform is secured with TLS. Cross-cell traffic travels over authenticated NATS connections, and probe nodes at the edge are handed only the narrowly-scoped credentials they need for the work they do, never the platform's signing keys.