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);
  },
};

My recommendation: in an interview, sketch this as "edge middleware" between users and your load balancer, label it with 3-4 things it handles, and draw a single arrow to origin for everything else. That's the whole story.

Key Components

Types / Variations

Edge runtimes differ significantly in execution model, resource limits, and cold start behavior. This determines what you can actually run at the edge.

The V8 isolate model (Cloudflare, Deno, Vercel) gives near-zero cold starts because isolates share a single process. Lambda@Edge uses containers, which explains the 100-500ms cold start penalty. For latency-sensitive edge work, isolates are almost always the right model.

Edge Data Stores

Running code at the edge is only useful if you can access data at the edge. The store you choose determines your consistency guarantees.

The rule of thumb: use KV for anything that tolerates 60-second staleness (most things), Durable Objects for coordination that needs exactness, and distributed SQLite when you need queries on small datasets.

Trade-offs

The fundamental tension is latency vs. operational simplicity. Edge computing trades the debuggability and consistency guarantees of a single-region deployment for sub-50ms response times to global users. The closer you move compute to users, the further you move it from your data and your debugging tools.

When to Use It / When to Avoid It

Use edge compute when:

• Auth and token validation: JWT verification at the edge rejects 100% of unauthenticated traffic without origin involvement. This is the single highest-value edge use case.
• Request routing and middleware: URL rewrites, header injection, A/B test assignment, bot detection. Anything that enriches or filters requests before they hit origin.
• Geolocation logic: Redirect users to regional domains, show localized content, enforce geo-restrictions. The edge runtime provides IP geolocation automatically.
• Personalized caching: Serve cached pages with personalized fragments (user name, locale, feature flags) by assembling responses at the edge from cached components.
• Rate limiting: Edge-based rate limiting blocks abuse before it reaches your infrastructure. Durable Objects or distributed counters make this feasible.
• Static site generation with dynamic headers: Add security headers, CORS, CSP to static responses without any origin involvement.

Avoid edge compute when:

• Your data lives in one region: If every edge function calls a centralized Postgres in Virginia, you've added edge compute latency on top of the database round-trip. The edge function completes in 2ms, then waits 150ms for the database. Net improvement: zero.
• You need strong consistency: Distributed edge state is eventually consistent by default. Financial transactions, inventory counts, and anything where stale reads cause real harm should stay at origin.
• The logic is CPU-intensive: Image processing, PDF generation, ML inference. Edge workers are optimized for I/O-bound tasks, not computation.
• You need full runtime APIs: Raw TCP connections, filesystem access, native extensions, or heavy dependencies. Edge runtimes are sandboxed.
• Your users are in one region: If 95% of your traffic comes from the US East Coast and your origin is in Virginia, edge compute adds architectural complexity with minimal latency benefit.

If you're unsure whether something belongs at the edge, it probably doesn't. Start with auth and routing, measure the impact, and expand from there.

Real-World Examples

Cloudflare Workers handles millions of requests per second across 300+ PoPs in 100+ countries. Discord uses Workers for rate limiting and request routing, processing every API request through edge middleware before it reaches origin. The 0ms cold start means no user ever waits for an isolate to spin up.

Vercel Edge Functions power Next.js middleware for authentication, redirects, and A/B testing. When you deploy a Next.js app on Vercel, the middleware.ts file runs at the edge by default. Companies like Washington Post and Notion use this to serve personalized content with sub-50ms time-to-first-byte globally.

Netflix Open Connect is a custom edge CDN that handles over 15% of all internet traffic globally. While primarily a caching system for video content (not general-purpose compute), it demonstrates the core principle: placing processing power close to users at ISP locations reduces latency and backbone bandwidth. Netflix stores copies of its content across 17,000+ servers in 6,000+ locations worldwide.

How This Shows Up in Interviews

When to bring it up

Mention edge computing when the interviewer asks about latency optimization for global users, when a CDN alone isn't sufficient for dynamic content, or when you're designing middleware/gateway layers. It fits naturally in auth discussions ("reject invalid tokens at the edge before they reach origin") and A/B testing systems ("assign cohorts at the edge with zero origin cost").

Depth expected at senior/staff level

• Edge vs. CDN distinction: Caching static content vs. running dynamic code. Different purposes, same physical locations.
• What belongs at edge vs. origin: Auth, routing, flags, geo-logic at edge. Complex business logic, writes, strong consistency at origin.
• Edge data stores: KV for config/flags (eventually consistent), Durable Objects for coordination (strongly consistent at one location), distributed SQLite for small queryable datasets.
• Cold start tradeoffs: V8 isolates (0ms) vs. containers (100-500ms) and why this drives runtime choice.
• The hybrid model: Edge handles auth/routing/caching, origin handles business logic and writes. Draw the separation explicitly.
• Blast radius: Bugs deploy to 300+ PoPs in seconds. Canary rollouts and feature-flag gating are essential.

Follow-up Q&A

Test Your Understanding

Quick Recap

1. Edge computing runs application code at CDN PoPs, cutting dynamic request latency from 150-300ms to 10-50ms by eliminating trans-oceanic round-trips.
2. Best edge use cases are stateless or eventually-consistent: JWT validation, A/B test assignment, geolocation routing, request/response transformation, and rate limiting.
3. V8 isolate runtimes (Cloudflare Workers, Deno Deploy, Vercel) have 0ms cold starts with 128MB/50ms limits. Container runtimes (Lambda@Edge) have 100-500ms cold starts but higher resource ceilings.
4. Edge data stores trade consistency for locality: KV gives 1ms reads with 60-second propagation, Durable Objects give strong consistency at one location with ~50ms reads, and distributed SQLite gives SQL queries on eventually-consistent replicas.
5. The edge-origin hybrid model is the standard: edge handles auth, routing, and caching while origin handles business logic, transactions, and strong-consistency operations.
6. Edge deployment blast radius is a real operational risk: code deploys to 300+ PoPs in seconds. Canary rollouts, automated rollback triggers, and feature-flag gating are essential safeguards.
7. The decision framework is simple: if the request is stateless or tolerates eventual consistency, and the latency savings matter for your user base, move it to the edge. Everything else stays at origin.

Related Concepts

• CDN: CDN caching is the static-content counterpart to edge compute. Understanding CDNs first makes edge compute a natural extension of the same infrastructure.
• Caching: Edge KV stores and per-PoP caches are caching strategies with specific consistency tradeoffs. The cache-aside pattern applies at the edge layer too.
• Networking: Understanding TCP round-trip time, TLS handshakes, and anycast DNS routing explains why edge compute provides such significant latency improvements for global users.