Edge computing, honestly

Edge computing has been sold as a general architectural improvement: run your code in hundreds of locations near users, everything gets faster.

The physics is real. The applicability is narrower than the marketing, and the reason is data.

the physics#

Light in fiber travels roughly 200,000 km/s. New York to London and back is about 55 ms of pure propagation, before any processing. Add TLS handshakes, TCP setup, and real-world routing that is not a great circle, and a cross-Atlantic round trip is frequently 100 ms or more.

Running code 20 ms from the user instead of 120 ms is a genuine improvement and it is not achievable any other way.

the problem#

Your data is not at the edge. It is in a database, in one region, and if your edge function needs it, you have moved the compute closer to the user and left the round trip in place — plus added a hop.

user → edge (5ms) → origin database (120ms) → edge → user

That is slower than the user talking to the origin directly, because you added a hop to a path that was always dominated by the database call.

This is the single most common edge computing mistake and it is easy to make, because the architecture diagram looks right.

what edge is genuinely good for#

Anything that needs no origin data:

• Redirects and rewrites. URL normalization, locale routing, legacy path mapping.
• Authentication token validation. A signed JWT can be verified with a public key at the edge, and an invalid request never reaches your origin. This is a real win — you reject bad traffic at the perimeter.
• A/B test assignment. Deterministic hash of a cookie into a bucket. No state required.
• Header manipulation. Security headers, CORS, feature policy.
• Bot filtering and rate limiting. Reject at the edge, before the request costs you anything.
• Personalization of cached content. Fetch the cached page, inject the user's name from a cookie, return. The expensive part stays cached.

Anything where the data is genuinely replicated to the edge:

Several platforms now offer edge-replicated key-value and SQL storage. If your data is small, read-heavy, and tolerant of replication lag — configuration, feature flags, product catalogs, translations — this works well and the latency win is real.

The constraints are real too: writes go to a primary, replication is eventual, and storage per location is limited.

what edge is bad for#

Anything write-heavy. Writes need coordination. Coordination needs a primary. The primary is in one place.

Anything requiring strong consistency. By definition, this needs coordination, which needs round trips, which is what you were trying to avoid.

Anything with a large working set. You cannot replicate a terabyte to three hundred locations.

Anything computationally heavy. Edge runtimes have tight CPU and memory limits. They are designed for milliseconds of work per request.

Anything that needs a specific runtime. Most edge platforms run a constrained JavaScript or WebAssembly environment. Your Python dependency with a C extension is not going there.

the architecture that works#

Layered, with each layer doing what it is good at:

edge      → auth check, rate limit, routing, cached content, header work
regional  → application logic, caching, session state
origin    → the database, the writes, the truth

Most requests are answered at the edge from cache. Some go to a regional application tier. Few reach the origin.

That is a CDN with programmability, which is what edge computing actually is, and framing it that way produces much better decisions than framing it as "serverless everywhere."

the thing to measure first#

Before adopting any of this: where does your latency actually go?

Break down a typical request:

• DNS
• TLS handshake
• Network round trip
• Time to first byte at origin
• Origin processing
• Database time within that
• Response transfer

If origin processing is 400 ms and network is 40 ms, moving compute to the edge addresses 40 ms of a 440 ms problem. Fix the 400 first.

This is the most common reason edge adoption disappoints: it was applied to a latency problem that was not a network problem.

the honest summary#

Edge is a very good CDN with programmability, and that is genuinely valuable — it lets you do real work at the perimeter that used to require an origin request.

It is not a general application platform, and the platforms selling it as one are selling the constraint as a feature.

Use it for the perimeter. Keep your data where it can be consistent.