“Edge-first” has become a marketing term. Cloudflare, Vercel, Deno, Fastly, and a dozen other platforms have all claimed ownership of it, usually to describe something subtly different. Let me be specific about what it means in practice and when it actually makes sense.

What Edge-First Means

An edge-first architecture executes logic at the network edge, geographically close to your users, rather than in a centralized origin datacenter. Instead of every request traveling from a user in Tokyo to a server in us-east-1 and back, it’s handled by infrastructure in Tokyo.

The network round-trip alone is worth approximately 1ms per 100km of fiber. A user in Singapore hitting an origin in Virginia adds roughly 180ms of round-trip latency before your application does anything. Edge execution eliminates that.

But latency is only part of the story.

Where Edge Wins

Global audiences. If your users are distributed across multiple continents, edge is almost always the right choice for the request-handling layer. Even if your data is centralized, you can often push the hot path to the edge and only call the origin for cache misses or mutations.

High-volume, low-compute workloads. Authentication checks, request routing, A/B testing, rate limiting, and header manipulation are all operations that need to run on every request but don’t require heavy computation. Edge is ideal: you pay for execution time, and these operations are fast.

Static and near-static content. If your content changes infrequently and can be cached, the edge is the best CDN and the best application server simultaneously. Cloudflare Workers with static assets gives you sub-10ms cache hits at the edge, with no round trip to origin at all.

Predictable latency requirements. Edge compute has no cold starts (in the traditional sense). Cloudflare Workers, for example, start in under 1ms. If you have SLA commitments around P99 latency, edge removes the cold-start tail from the latency distribution entirely.

Where You Still Need an Origin

Long-running processes. Workers have a CPU time limit (currently 10ms on the free plan, 30ms on paid, up to 5 minutes with Durable Objects). Heavy compute (PDF generation, image processing, ML inference beyond Workers AI, large file uploads) needs a traditional server.

Complex database queries. Your database almost certainly lives in a specific region. If your application logic requires multiple round-trips to that database, executing that logic at the edge in Tokyo adds round-trip latency to every query. In this case, you’re paying for the edge hop without gaining anything.

The crossover point is roughly: if your application logic requires more than two synchronous calls to a centralized data store, you probably want to co-locate the logic with the data.

Stateful, long-lived connections. WebSockets and server-sent events work at the edge (Cloudflare has Durable Objects for this), but the implementation is non-trivial. If stateful connections are your primary pattern, evaluate carefully before committing to an edge-first approach.

The Hybrid Pattern

Most real-world architectures end up hybrid: an edge layer handling routing, auth, caching, and the hot path, with origin servers handling the long-tail of compute-heavy or data-heavy operations.

User → Edge Worker
          ↓ (cache miss or mutation)
       Origin API (co-located with DB)

The edge layer handles:

  • Authentication token validation (JWT verification is fast, ~1ms)
  • Request routing and rewriting
  • Rate limiting (Workers KV or Durable Objects)
  • Serving static assets from cache
  • A/B traffic splitting

The origin handles:

  • Database reads and writes
  • Background jobs
  • File storage operations
  • Third-party API orchestration

This pattern gives you the latency benefits of edge for the majority of traffic, while retaining the flexibility of a traditional server for operations that need it.

The Decision Framework

For a new project, we ask three questions:

  1. Where are the users? If concentrated in a single region, edge latency savings are marginal. Optimize for developer experience instead.

  2. What does the hot path do? If the most common request flow is read-heavy with few origin calls, edge is a strong fit. If it’s compute-heavy or requires multiple DB queries, start with origin.

  3. What are the team’s constraints? Edge runtimes have a different programming model than Node.js: no filesystem, limited native Node modules, execution time limits. Assess the learning curve against the latency benefit.

Edge-first is the right default for most web applications built today. But “default” doesn’t mean “always.” Know what you’re optimizing for before you commit to the architecture.