Edge and cloud are not alternatives. They're positions on a spectrum defined by one variable: how far computation is from the request origin.
Cloud compute runs in a fixed set of regions. Requests route to the nearest one — which may still be 100–200ms from the client. All state is centralized and consistent.
Edge compute runs in dozens to hundreds of locations, colocated with network exchange points. Cloudflare Workers execute in 300+ cities. The tradeoff: constrained runtime, no persistent filesystem, execution time caps, and no shared memory between requests.
Structural differences
| Dimension | Cloud | Edge |
|---|---|---|
| Latency (P50) | 50–200ms | <20ms |
| State | Centralized, strongly consistent | Distributed or stateless |
| Runtime | Unrestricted (VMs, containers) | Constrained (V8 isolates, Wasm) |
| Cold start | Seconds (containers) | <5ms (isolate reuse) |
| Execution limit | Hours | 30ms–30s CPU time |
| Cost unit | Compute time + egress | Requests + CPU ms |
The edge trades runtime flexibility for proximity. The cloud trades proximity for power.
What runs where
Run at the edge:
- Auth token validation and request rejection before traffic hits origin
- A/B routing and feature flag evaluation
- Geo-aware content selection or redirect
- Response header injection (CORS, cache-control, CSP)
- Caching and cache revalidation close to users
- Rate limiting and bot filtering
Run in the cloud:
- Long-running batch jobs and background workers
- Stateful workloads requiring persistent connections (WebSocket hubs, queues)
- Complex relational queries against a centralized database
- Workloads requiring >512MB memory or extended CPU time
- ML inference on large models
The edge is a filter and accelerator. The cloud is where the work happens.
The hybrid model
Most production systems use both. Edge handles traffic shaping, auth, and cache; cloud handles business logic and persistence. The edge calls origin only on a cache miss or when dynamic data is required.
Client
│
▼
Edge Worker
├─ cache hit? → return cached response
├─ auth fail? → 401, no origin call
└─ cache miss → fetch from Cloud API
│
▼
Cloud API + DB
│
Edge caches result
│
Client receives responseThis structure removes a round-trip to the cloud for the majority of requests — the cache hit path never reaches origin.
The consistency constraint
The primary limitation of the edge is state. Cloudflare KV is eventually consistent — a write in one region propagates to others within seconds, not milliseconds. Cloudflare Durable Objects provide strongly consistent state but pin to a single location, introducing latency from distant users.
If your workload requires real-time consistent state reads across all regions (financial transactions, inventory systems, session tokens), the edge is not the right layer for that logic. Handle it at origin, use the edge only for the read path.
When to commit to edge-first
Edge-first is the right default when your application is primarily read-heavy, geographically distributed, and latency-sensitive. Static content, content APIs, auth checks, and routing are natural fits.
Move to origin — or treat edge as a pass-through — when your logic requires consistent state, significant memory, or complex computation that exceeds the constrained runtime.