Skip to main content
Let's talk
Back to all posts
Architecture · 3 min read

Edge architecture: when it pays off and when it doesn't

Edge runtimes are hyped for everything and perfect for maybe 20% of workloads. Here's the one question that tells you which camp you're in before you write a line of code.

Written by Brayan Oduro

Every six months a new “edge-first” framework launches and the discourse resets. The honest answer is that edge runtimes are a fantastic fit for about 20% of workloads and a tax on the other 80%.

Here’s how I decide.

The 20% where edge wins outright

Three patterns where the math is unambiguous:

  1. Stateless request/response APIs that need to be globally fast. Auth checks, feature flags, geolocation routing, image transforms. Cold start is your enemy — and edge has none.
  2. Webhook ingestion that fans out. Receive, verify signature, enqueue. The whole work unit is under 50ms. Paying for a permanent server makes no sense.
  3. Personal/side projects where ops cost matters more than peak performance. Zero servers, zero patching, zero alarms.

The 80% where edge is the wrong tool

The failure modes are predictable:

  1. Long-running compute. Edge workers have CPU time limits. Report generation, PDF rendering, batch transformations — these belong on a regular server.
  2. Heavy native dependencies. Node crypto, sharp, anything with a native binding. The V8 subset is real, even with Node compatibility flags.
  3. Persistent connections. WebSockets at scale, database connection pooling, stateful sessions. Edge has no memory between requests and no way to hold a connection open.

Yes, workarounds exist for all of these. They’re workarounds.

The single best signal: if your request handler runs over 500ms of CPU time, you’re fighting the runtime, not using it.

What “edge” actually changes about your code

People talk about edge as a deployment choice. It’s really a programming model choice:

  • No filesystem to write to → all state externalized.
  • Streaming-first → your handlers return Response objects, not JSON blobs.
  • Limited Node APIs → the V8 subset is real, even with Node compatibility flags.
  • Sub-request limits → you can’t fan out 200 parallel calls in one handler.

If those constraints feel liberating, edge will make you faster. If they feel suffocating, stay on a traditional Node runtime. There’s no shame.

The hybrid pattern I actually ship

For most products I now run a small edge proxy layer in front of a regular Node backend:

  • Edge handles: auth, geo, caching, rate limiting, lightweight reads.
  • Node handles: database transactions, background jobs, anything stateful.

This gives you fast TTFB on the boring 80% of requests without rewriting the parts of your app that have no business being on the edge.

It’s the boring answer. It’s also the one that works.