Edge computing

TL;DR

• Edge computing runs application logic at CDN Points of Presence (PoPs) close to users, cutting dynamic request latency from 150-300ms to 10-50ms.
• Best edge use cases: JWT validation, A/B test assignment, geolocation routing, request/response headers, bot detection. All stateless or eventually-consistent workloads.
• Edge runtimes use V8 isolates (not containers), giving near-zero cold starts but strict limits: ~128MB RAM, 50ms CPU time, no blocking 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 perfectly. Images, CSS, JavaScript bundles all 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.

I've seen teams spend months optimizing database queries and application code, shaving off 10ms here and 20ms there, while ignoring the 300ms physics tax on every cross-ocean request. No amount of code optimization fixes the speed of light.

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 many applications, 60-80% of requests can be fully resolved at the edge without ever touching origin.

For your interview: say "edge compute runs application logic at CDN PoPs so we can handle auth, routing, and personalization in 10ms instead of 300ms" and move on.

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 nearest PoP. Your domain uses anycast DNS, so the user's request routes to the São Paulo PoP automatically. Latency: ~5ms.
2. TLS terminates at the edge. The edge worker handles the TLS handshake locally, saving one full round-trip (~150ms for users far from origin).
3. Edge worker executes. The V8 isolate spins up in under 1ms (no container cold start). The worker runs your middleware logic.
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);
  },
};