1. Do the Physics First#

Most articles about edge computing start with “fast,” but the more accurate starting point is “far.”

The lower bound on a network request isn’t bandwidth—it’s the speed of light. The straight-line distance from Beijing to Virginia is about 11,000 kilometers, and the actual fiber route is even longer. Light travels through fiber at roughly 200,000 km/s. A rough estimate: about 60–75 ms one way, and once you add a TCP + TLS handshake plus request-response, the physical floor is already around 150 ms—and that latency has nothing to do with how fast the server is or how well the code is written.

1
User (Beijing)  ──75ms──▶  Origin server (Virginia) ──75ms──▶  User
2
                  Total ≈ 150ms, not even counting application processing time

Move that same logic to a node a few hundred kilometers from the user, and the math drops to single-digit milliseconds. That’s the one thing edge computing is really trying to solve: shortening the physical round-trip distance, not making the CPU faster.

My own blog is a ready-made example. Static pages have a CDN, so they’re fast to access worldwide; but the site’s AI chat assistant needs a dynamic endpoint to forward requests to DeepSeek’s API. If that layer sat on the origin server, every message a user sends would have to cross the Pacific. Instead, it now runs in workers/chat-proxy/, as a Cloudflare Worker deployed at the edge node closest to the user.

2. Centralized vs. Edge Request Paths#

One diagram makes the difference clear:

The key is that last arrow back to the origin. Edge computing doesn’t make “reading a database” or “running heavy logic” faster—if you really do have to go back to the origin, latency will only be worse than connecting directly to the origin, because you’ve added an extra hop. What it actually eliminates is the requests that would have had to go back to the origin anyway: authentication, redirects, A/B routing, CORS preflight, cache-hit checks, assembling static assets. What these all have in common is that they’re stateless, cheap to compute, and executed on every request—exactly the edge’s territory.

3. Runtime: What V8 Isolates Actually Save#

Traditional Serverless (the AWS Lambda kind) prepares a container for each function instance, and a cold start has to spin up an entire language runtime, usually hundreds of milliseconds. Cloudflare Workers takes a different approach: V8 isolates—a single process can host hundreds or thousands of isolated execution contexts at once.

According to Cloudflare’s official docs: isolates start about 100 times faster than Node processes on containers or virtual machines, and use an order of magnitude less memory at startup. Because the runtime is loaded only once, each new isolate just “carves out” a small chunk of memory afterward.

But the same docs contain a reminder that’s easy to overlook, and it determines almost every engineering decision that follows:

An isolate isn’t necessarily long-lived; it may be reclaimed due to resource limits, so don’t store mutable state in the global scope.

In other words, the edge runtime is a “temp worker” that could be swapped out at any moment. Its speed comes from the shared process, and the price is that it can’t hold state for long. This constraint directly rewrites many habitual patterns—rate limiting, for example.

4. Limits You Must Remember#

The edge isn’t cheap compute without a cost. The following numbers come from Cloudflare Workers’ official Limits documentation (free / paid):

Two points are especially worth noting:

• 128MB is a hard limit, and paying can’t raise it. It’s completely different from the AWS Lambda model of “pay more, buy more memory.” The official mitigation advice is straightforward: use streaming (TransformStream) instead of reading the entire response into memory, and put large files in R2/KV.
• CPU time is compute time, excluding waiting on I/O and network. So “calling a slow API” won’t blow the 10ms limit, but “parsing a 5MB JSON at the edge” will.

Together, these two points explain exactly why this site’s Worker is written the way it is when forwarding DeepSeek’s streaming response:

1
//Hand the upstream ReadableStream directly to the client, without reading it into memory or buffering
2
return new Response(response.body, {
3
  headers: {
4
    ...corsHeaders(origin),
5
    'Content-Type': 'text/event-stream',
6
    'Cache-Control': 'no-cache',
7
  },
8
});

5. In Practice: Taking This Site’s Chat Proxy Apart#

This Worker is only 190 lines, but every line responds to that list of limits above. Let’s look at three spots.

1
// Exact-match CORS allowlist. Do NOT use prefix matching here: an origin such
2
// as "https://www.example.com.evil.com" must never pass the check.
3
const ALLOWED_ORIGINS = new Set([
4
  'https://www.example.com',
5
  'https://example.com',
6
  'http://localhost:4321',
7
]);

1
async function isRateLimited(ip: string): Promise<boolean> {
2
  const now = Date.now();
3
  // Fake URL: the Cache API requires a full URL as the key.
4
  const key = `https://chat-proxy-ratelimit/${encodeURIComponent(ip)}`;
5
  try {
6
    const cache = caches.default;
7
    const cached = await cache.match(key);
8
    let state: RateLimitState = { windowStart: now, count: 0 };
9
    if (cached) {
10
      try {
11
        state = JSON.parse(await cached.text()) as RateLimitState;
12
      } catch {
13
        state = { windowStart: now, count: 0 };
14
      }
15
    }
16
    if (now - state.windowStart >= RATE_LIMIT_WINDOW_MS) {
17
      state = { windowStart: now, count: 0 };
18
    }
19
    state.count += 1;
20
    // Responses are only stored when they carry a Cache-Control header.
21
    await cache.put(
22
      key,
23
      new Response(JSON.stringify(state), {
24
        headers: { 'Cache-Control': `max-age=${Math.ceil(RATE_LIMIT_WINDOW_MS / 1000)}` },
25
      }),
26
    );
27
    return state.count > RATE_LIMIT_MAX_REQUESTS;
28
  } catch {
29
    // Fail open: never let a rate-limit storage error block legitimate traffic.
30
    return false;
31
  }
32
}

1
// Sanitize: keep only user/assistant turns (never let the client inject a
2
// system prompt) and bound the total payload size.
3
const messages = body.messages
4
  .filter(
5
    (m): m is { role: 'user' | 'assistant'; content: string } =>
6
      !!m && ALLOWED_ROLES.has(m.role ?? '') && typeof m.content === 'string',
7
  )
8
  .map((m) => ({ role: m.role, content: m.content.trim().slice(0, MAX_TOTAL_CHARS) }));

6. Three Common Pitfalls#

7. When Not to Put It at the Edge#

The edge is not the default option. For the following scenarios, putting things there will only make them slower or more expensive:

• Heavy CPU logic: Image transcoding, large file parsing, model inference—the free tier’s 10ms CPU budget gets blown in a few milliseconds.
• Strongly consistent writes: Writes that need transactions or uniqueness constraints ultimately have to go back to a real database.
• Purely static content: The CDN is already handling it; wrapping another Worker around it just adds another failure surface.
• Debugging-first phases: Logging, breakpoints, and dependency troubleshooting in edge environments are all weaker than on regular servers. Before features are stable, it’s not worth paying this cost upfront for latency.

A simple rule of thumb:

Does this logic run on every request, is it stateless, and are both inputs and outputs small? If yes, it’s a good fit for the edge; if not, keep it on the origin.

8. Conclusion#

Edge computing is often packaged as “a faster server,” but its true shape is closer to “moving the small logic that was already going to repeat on every request from a long-distance call to a corner convenience store.” The 100-plus milliseconds saved by physical distance is real; the 128MB memory, 10ms CPU, and no dependable local state—these constraints are real too. Understanding this trade-off clearly matters far more than memorizing any particular platform’s API.

References#

• Cloudflare Workers — Limits (128MB memory, CPU time, 1s startup, subrequest and bundle size limits)
• Cloudflare Workers — How Workers works (differences between isolates and containers, startup speed and memory comparison, isolates may be evicted)
• Cloudflare Workers — Node.js compatibility (nodejs_compat flag, enabled by default as of 2026-08-04, unenv polyfill behavior)
• Vercel — Edge Runtime (the subset of Web APIs supported by Edge Runtime and unsupported items)
• Vercel — How can I make my library compatible with the Vercel Edge Runtime? (does not support fs, require, eval, etc., and recommends the Node.js runtime by default)