Edge Computing in 2025: Architecting Systems That Live at the Network's Edge

The pitch for edge computing is simple: put the compute closer to the user and cut the latency. Why route a request from Warsaw to us-east-1 when you could run the logic in Frankfurt and respond in under 5ms? The pitch is basically right. But here's what the marketing doesn't tell you: most teams don't need edge yet, and the ones that adopt it prematurely spend a lot of time fighting operational complexity they didn't sign up for.

This is a guide for engineers who want to understand edge rigorously: what it actually is, where it delivers real value, where it creates real pain, and how to build production systems on it without losing your mind over consistency and observability.

Edge vs Cloud vs CDN: What Is Actually Different

CDNs cache static assets at edge nodes and serve them without touching your origin. Traditional cloud runs in a handful of regions (us-east-1, eu-west-1, ap-southeast-1) and requires a round-trip for every dynamic request. Edge compute sits between these two: it runs arbitrary code at CDN-like distribution density, handling dynamic requests without that central round-trip.

The practical difference is latency. A user in Warsaw hitting a us-east-1 origin faces roughly 110ms of network round-trip before your code even starts running. The same request hitting a Cloudflare Worker in Frankfurt executes in under 5ms of network time, with another 1-2ms for the actual compute. For real-time features, that gap is the difference between a product that feels alive and one that feels sluggish.

The key constraint: edge runtimes are not Node.js. They expose a subset of Web APIs (Fetch, SubtleCrypto, Cache, Streams) but skip Node internals entirely. No filesystem access, no child processes, no npm packages that depend on native bindings. This is by design. Cold starts must stay under 5ms, which requires a lighter runtime model. If your code assumes Node, you'll hit walls fast.

Edge Function Platforms: A Realistic Comparison

Three platforms handle the majority of production edge compute workloads in 2025. They're more different from each other than the marketing suggests.

Cloudflare Workers

Workers run on the V8 isolate model, the same JavaScript engine as Chrome, but without Node.js underneath. Cold starts are under 1ms because isolates share the same process without startup overhead. Workers run in 300+ points of presence, have deep integration with Cloudflare's network primitives (KV, D1, R2, Durable Objects, Queues), and support TypeScript natively. For most teams, Cloudflare Workers is the right default for edge compute. It's the most mature ecosystem by a significant margin.

Fastly Compute

Fastly Compute uses WebAssembly instead of V8 isolates, which lets you compile Rust, Go, or AssemblyScript to Wasm and run it at the edge. This is genuinely useful for CPU-intensive workloads where Wasm can outperform interpreted JavaScript. The tradeoff: a smaller PoP footprint (around 80 locations) and a less mature tooling ecosystem. Fastly makes sense when language flexibility or raw compute performance is the primary driver.

AWS Lambda@Edge and CloudFront Functions

Lambda@Edge and Cloudflare Workers are often mentioned in the same breath, but they're really different products solving different things. Lambda@Edge runs full Node.js 18/20 runtimes at CloudFront PoPs, but cold starts run 100-500ms and execution is regional rather than truly global. CloudFront Functions (the lighter variant) are closer to Workers in model but are restricted to JavaScript with a 10ms CPU time limit. For teams committed to AWS, Lambda@Edge handles complex use cases. CloudFront Functions handles request/response manipulation. Neither should be your first choice if you're picking fresh.

Edge Databases and Data Synchronization

Stateless edge functions are straightforward. The hard problem is data. If your Worker needs to read user preferences, feature flags, or session state, you can't round-trip to a Postgres instance in us-east-1 without destroying your latency advantage. This is where most edge architectures get complicated.

Cloudflare KV

KV is an eventually consistent key-value store replicated to all Cloudflare PoPs. Reads are served locally with sub-millisecond latency. Writes propagate globally within 60 seconds. It's suitable for feature flags, configuration, and read-heavy workloads where stale reads are acceptable. It's not suitable for counters, inventory, or anything requiring strong consistency. Know this going in.

Cloudflare D1 and Distributed SQLite

D1 is Cloudflare's SQLite-based relational database that runs within the Cloudflare network. Writes go to the primary, reads are served from replicas that may be 1-2 seconds behind. Turso (built on libSQL, a SQLite fork) offers a similar model with more control over replica placement and a standalone service you can use from any runtime. For applications that need SQL semantics without strict strong consistency, distributed SQLite is a genuinely compelling option. I've seen teams get surprised by the consistency lag, so go in with clear expectations about what you can and can't do.

Upstash Redis

Upstash provides a Redis-compatible HTTP API designed for edge environments. Since edge runtimes don't have persistent TCP connections, Upstash's REST API is a natural fit. Well-suited for rate limiting, session caching, and leaderboards, where Redis semantics matter and eventual consistency is fine.

Stateful Edge: Durable Objects and Global Coordination

Durable Objects are Cloudflare's solution to the stateful edge problem, and they're one of the more interesting primitives in the space. Each Durable Object is a single-threaded JavaScript actor with its own persistent storage, addressable by a unique ID. All requests to a given Durable Object ID are routed to a single instance worldwide. That gives you strongly consistent, low-latency coordination without a central database.

Classic use cases: real-time collaboration (a Durable Object per document), presence tracking (a Durable Object per room), rate limiting (a Durable Object per user), and WebSocket connection management. Here's a minimal room coordinator:

export class RoomCoordinator implements DurableObject {
  private sessions: Map<WebSocket, { userId: string }> = new Map()
  private storage: DurableObjectStorage

  constructor(state: DurableObjectState) {
    this.storage = state.storage
  }

  async fetch(request: Request): Promise<Response> {
    if (request.headers.get('Upgrade') !== 'websocket') {
      return new Response('Expected WebSocket', { status: 426 })
    }
    const [client, server] = Object.values(new WebSocketPair())
    server.accept()

    const userId = new URL(request.url).searchParams.get('userId') ?? 'anon'
    this.sessions.set(server, { userId })

    server.addEventListener('message', (evt) => {
      this.broadcast(evt.data as string, server)
    })
    server.addEventListener('close', () => {
      this.sessions.delete(server)
    })

    return new Response(null, { status: 101, webSocket: client })
  }

  private broadcast(message: string, sender: WebSocket) {
    for (const [ws] of this.sessions) {
      if (ws !== sender && ws.readyState === WebSocket.READY_STATE_OPEN) {
        ws.send(message)
      }
    }
  }
}

The routing Worker just derives the Durable Object ID from the room identifier and forwards the request. The result is a globally consistent, real-time coordination primitive with no external database. That's genuinely impressive engineering.

IoT and On-Device Edge Computing

For IoT workloads, "edge" means something different: compute runs on gateway hardware at the facility level, not in a CDN PoP. This distinction matters architecturally. Industrial sensors can't tolerate a 200ms round-trip to the cloud for each measurement, so the logic has to run locally.

The standard stack: MQTT for device-to-gateway messaging, a local message broker (Mosquitto or EMQX), and a processing layer running TensorFlow Lite or ONNX Runtime for on-device ML inference. OTA update management is handled by platforms like Mender or Balena. The pattern is: sensors publish to a local MQTT broker, a gateway process applies anomaly detection models, and only aggregated results or anomaly alerts get forwarded to the cloud. This reduces upstream bandwidth by 90%+ while keeping response latency under 10ms.

Edge Observability: Tracing Across 300+ PoPs

Observability is where most edge deployments struggle. Traditional APM tools assume a handful of regional deployments. Distributed tracing across 300+ PoPs with millisecond execution windows requires a different approach, and most teams don't think about this until they're already in production.

Cloudflare's built-in analytics surface request volume, error rates, and CPU time per Worker. For end-to-end tracing, you need to propagate W3C TraceContext headers and ship spans to an OTLP-compatible backend (Honeycomb, Grafana Tempo, or Baselime). Spans can't be sent synchronously in the hot path. Use ctx.waitUntil() to flush telemetry after the response is sent, and batch spans to minimize egress costs.

For error tracking, Sentry's edge SDK supports Cloudflare Workers and correctly captures source maps and breadcrumbs. Set up sampling aggressively: 100% sampling across 300 PoPs at high traffic generates enormous ingest volumes. A 1-5% sample rate with 100% sampling for errors is a reasonable starting point.

Cache Invalidation at the Edge

Cache invalidation is famously hard. At the edge, geographic distribution makes it more complicated. When you update a product price or expire a session, you need that change to propagate to all PoPs promptly without over-purging and creating origin stampedes.

Cloudflare's Cache API within Workers gives you programmatic control: purge by cache tag, by URL, or by prefix. Tag-based invalidation is the most scalable: tag cached responses with entity identifiers (like product-12345) and purge by tag on mutation. This lets you invalidate precisely without touching unrelated entries. Combine this with surrogate key headers on your origin responses and you get an invalidation system that's both precise and fast (global propagation in under 5 seconds).

Cold Start vs Warm Start on Edge Runtimes

The V8 isolate model used by Cloudflare Workers effectively eliminates cold starts as traditionally understood. There's no container to spin up, no Node.js process to fork. A new isolate is created from a pre-compiled snapshot in under 1ms. That's why Workers can advertise sub-5ms p99 latencies even for brand-new deployments.

Lambda@Edge, by contrast, uses full Lambda execution environments and can take 100-500ms to initialize a cold instance. If your Lambda@Edge function handles authentication or routing and fires on every request, cold starts will show up in your p99 tail latency. You can mitigate this with provisioned concurrency, but budget accordingly.

Worker bundle size affects parse time, so keep bundles lean. Split code with dynamic imports where the hot path is small. Minified production Workers should stay under 1MB. The hard limit is 10MB.

When NOT to Use Edge

My honest take: edge is right for maybe 10-20% of teams right now. Here's when to stay in a traditional cloud region instead.

Avoid edge when your logic requires long-running compute (Workers have a 30-second CPU limit in the paid tier, 10ms on the free tier), heavy database transactions requiring strict ACID guarantees across multiple tables, access to large in-process state or caches that need to be warm (isolates don't share memory between requests), or operations that depend on native Node.js modules or OS-level capabilities.

Heavy ML inference belongs on GPU instances, not edge runtimes, unless you're running quantized models under 10MB in WebAssembly. Background job processing, complex ETL pipelines, and anything talking to a private VPC database on TCP should stay in a traditional cloud region. Think of edge as a compute layer for request-response transformations where global latency is the primary concern.

Practical Use Cases Worth Pursuing Today

The workloads delivering the clearest return from edge in 2025: JWT verification and session validation (eliminate the auth round-trip before serving protected content), A/B test assignment (assign cohorts at the edge, set a cookie, forward to the right origin variant), geo-based content routing (serve region-specific pricing or redirects without origin involvement), rate limiting (Durable Objects provide strongly consistent rate limit counters without a Redis round-trip), and edge-side rendering of personalized HTML fragments injected into otherwise static pages.

The ecosystem is mature enough that these workloads carry low adoption risk. Start with one well-understood use case: authentication middleware is ideal for a first project. Instrument it thoroughly, and expand from there. The companies building edge infrastructure, Cloudflare especially, are some of the most interesting infrastructure bets of the decade. The latency improvements for globally distributed users are genuine and often dramatic. Done carefully, edge computing is one of the highest-leverage infrastructure investments available to product engineering teams today.