What happens between a request and a response
How a node is chosen, what keeps it honest, and the four hops a request actually takes.
TL;DR
Your content is signed and split into encrypted chunks. Chunks are stored on nodes in metro areas where they are most in demand. When someone requests your content, our resolver connects them to a node that is nearby, healthy and holding what they need. The node serves it to them over TLS and is credited for the bytes.
The important parts are how a node is chosen, and what keeps it honest.
How a node is chosen
Resolution happens at the DNS layer, like any other https request. The resolver scores target nodes on three criteria: network distance measured in observed latency, current load, and whether the node holds the chunks for this request.
Nodes that are physically nearer but already saturated will lose to others.
What keeps a node honest
Every object is hashed at deployment and the hashes are signed into a manifest. The visitor is served only content with the matching hash. Content with an altered byte would fail verification, so the request would be retried elsewhere.
The node is never trusted. That's by design — trusting thousands of strangers' computers would be the obvious objection, so we built a system where trust isn't necessary.
The four hops, in order
Origin
Your build, signed once at deployment.
Metro area gateway
Absorbs cache misses so your origin is not hit repeatedly.
Edge Node
Someone's machine, holding encrypted chunks.
Visitor
Verifies the hash, renders the page.
Now pick a side
Deploy to the network, or host your part of it.