Edge computing

Introduction

Edge computing places small, latency-sensitive decisions near users while durable business state and complex transactions usually remain in an origin region. Mental model: the edge is a distributed filter, router, and cache; the origin remains the authority for work that needs full runtime capabilities or strong consistency. The design only helps when the work and the data it needs are both close enough to benefit.

TL;DR

• Edge computing runs application logic at CDN Points of Presence (PoPs) close to users. It can cut dynamic request latency from 150-300ms to 10-50ms when the request is resolved at the edge; a request that still calls a distant origin keeps that network cost.
• Best edge use cases include JWT validation, A/B test assignment, geolocation routing, request/response headers, and bot detection. They are usually stateless or tolerate eventual consistency.
• Many edge runtimes use V8 isolates rather than containers, giving near-zero startup overhead but strict, provider-specific limits on memory, CPU time, APIs, and I/O.
• Edge data stores (KV, Durable Objects, distributed SQLite) make stateful edge logic possible, but with consistency tradeoffs that you need to design around.
• The fundamental question is not "can I run this at the edge?" but "does the latency win justify running code in 300+ distributed locations?"

The Problem It Solves

Your CDN handles static assets well in this illustrative scenario: images, CSS, and JavaScript bundles serve from the nearest PoP in under 20ms. But the moment a user hits a dynamic endpoint (login, personalized homepage, API call), the request flies past the CDN and travels to your origin server, often on another continent.

A user in Tokyo making a request to your origin in Virginia faces a minimum 150ms network round-trip just for the speed of light through fiber. Add TLS handshake, server processing, and database queries, and you're looking at 300-500ms for a single dynamic request. Multiply that by the 3-5 sequential API calls a typical page load makes, and your Tokyo users experience 1-2 seconds of latency that your Virginia users never see.

That 300ms network cost cannot be removed by local query optimization; it needs locality, caching, or a multi-region data strategy.

The CDN is right there in Tokyo, 10ms from the user, but it can only serve cached files. Every dynamic request bypasses it entirely. Edge computing changes this: what if the CDN node could also run your application logic?

What Is It?

Edge computing means running application logic at the same physical locations where CDNs serve static content, typically 200-300+ data centers distributed globally. Instead of every dynamic request traveling to a centralized origin, the edge node closest to the user handles it locally.

Think of it like a bank. Traditional web architecture is like a bank with one central office: every customer, no matter which branch they walk into, has to call the central office and wait for an answer. Edge computing puts a teller at every branch who can handle common transactions (verify your ID, check your balance) locally, and only calls the central office for complex operations (wire transfers, loan approvals).

The key insight: the edge handles what it can (auth, routing, personalization), and forwards only what it must to the origin. For workloads with cacheable or deterministic decisions, a large share of requests can be resolved at the edge without touching origin; measure that share rather than assuming it.

The two can be combined: a worker may make a cache decision, transform a request, or assemble a response from cached data before forwarding only the work that needs the origin.

How It Works

Let's trace a single request through an edge worker from start to finish. A user in São Paulo loads your dashboard.

1. DNS resolves to a nearby PoP. Your domain uses anycast or provider routing, so the user's request typically reaches a nearby São Paulo PoP based on network topology. Latency: ~5ms in this illustrative path.
2. TLS terminates at the edge. The edge worker handles the TLS handshake locally, which can avoid a round-trip to a distant origin.
3. Edge worker executes. An isolate starts without a container-scale cold start, then runs within the provider's CPU, memory, and API budgets.
4. Auth check. The worker verifies the JWT signature using a cached public key. Invalid tokens get a 401 immediately, never reaching origin.
5. Feature flag lookup. The worker reads feature flags from edge KV (~1ms). No origin round-trip needed.
6. A/B test assignment. The worker deterministically assigns the user to a cohort based on a hash of their user ID. Sets a cookie, selects the correct variant.
7. Decision: edge or origin? If the request can be fully served (auth rejection, cached response, A/B redirect), the worker responds directly. If it needs fresh data, the worker forwards to origin with enriched headers.
8. Origin handles complex logic. The origin receives a pre-authenticated, pre-enriched request. It queries the database, runs business logic, returns the response.
9. Edge caches the response. If the response is cacheable, the worker stores it at the local PoP for future requests from that region.

// Cloudflare Worker: edge middleware for auth + A/B + geolocation
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // 1. Verify JWT at the edge (no origin round-trip for invalid tokens)
    const token = request.headers.get("Authorization")?.replace("Bearer ", "");
    if (!token) return new Response("Unauthorized", { status: 401 });

    const isValid = await verifyJWT(token, env.JWT_PUBLIC_KEY);
    if (!isValid) return new Response("Invalid token", { status: 401 });

    // 2. Read feature flags from edge KV (~1ms)
    const flags = await env.FLAGS_KV.get("feature-flags", "json");

    // 3. Deterministic A/B assignment (no database needed)
    const userId = decodeJWT(token).sub;
    const cohort = hashToPercent(userId) < 50 ? "control" : "variant-a";

    // 4. Geolocation (provided by the edge runtime automatically)
    const country = request.cf?.country || "US";

    // 5. Forward to origin with enriched headers
    const originReq = new Request(env.ORIGIN_URL + new URL(request.url).pathname, {
      headers: {
        ...Object.fromEntries(request.headers),
        "X-User-Id": userId,
        "X-AB-Cohort": cohort,
        "X-Country": country,
        "X-Feature-Flags": JSON.stringify(flags),
      },
    });

    return fetch(originReq);
  },
};