Loading page
About this tool
Model whether an endpoint is faster at the edge or at the origin using round-trip latency, data locality, cache hit ratio and hard blockers.
This helper decides whether an API endpoint belongs on an edge runtime or at the origin by modelling the latency that actually matters: edge latency = user-to-edge RTT + (miss rate × origin data calls × edge-to-origin RTT), compared against simply serving from the origin region. It also applies the hard blockers — strong consistency against a single-region database, compute beyond edge runtime limits, and data-residency rules — that force origin regardless of latency. It is for developers choosing between edge functions (Cloudflare Workers, Vercel Edge, Lambda@Edge) and regional serverless or servers.
Open Edge vs Origin Decision Helper on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
The miss-rate × round-trips × RTT cost of reaching back to your data is computed, not hand-waved.
Consistency, compute limits and data residency override the latency maths when they apply.
When origin wins, it tells you what would change the answer — replicate data, batch calls, or split the endpoint.
When it can answer without crossing back to the origin region — static or cached content, redirects, auth-token checks against replicated data, geolocation logic. If every request still makes an uncached call to a single-region database, the edge adds a hop instead of removing one and is often slower.
It is the extra latency an edge function pays each time it fetches data from the origin region: the full edge-to-origin round trip, repeated for every sequential call. Two 100 ms round trips from an edge PoP cost 200 ms — more than many users would spend just reaching the origin directly.
Endpoints needing strong read-after-write consistency against a single-region primary, heavy CPU or memory beyond edge runtime limits, long-running work, or processing pinned to a region by data-residency rules. For these, edge execution either cannot work or saves nothing because every request must reach the origin anyway.
Raise the edge hit ratio so most requests never leave the PoP: cache responses or query results at the edge, use a globally replicated store (edge KV, read replicas) for read-mostly data, and collapse multiple sequential origin calls into one batched request. The model shows the break-even hit ratio for your RTTs.