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.
The Edge vs Origin Decision 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.
Enter the three round trips in ms: User → nearest edge RTT, User → origin region RTT and Edge PoP → origin region RTT.
Set the sequential origin data calls per request, the edge cache / replica hit ratio (%) and the handler compute time (ms), then tick any hard blockers — consistency, compute limits or data residency — that force origin.
Read whether to run the endpoint at the edge or the origin, with expected latency each way, the origin data cost from the edge and the break-even cache-hit ratio; press "Copy analysis".
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.