Chapter 2: Deployment Patterns That Actually Work
Once you accept that edge means trading per-CPU cost for latency, the next question is which deployment pattern fits your workload. There are three that account for 90 percent of production edge systems: CDN functions, regional PoPs, and device-edge orchestration.
CDN functions
The dominant pattern for 2025. Cloudflare Workers, Fastly Compute, Deno Deploy. Run JavaScript or WASM at hundreds of POPs. The pattern works for:
- Auth token verification
- Request routing and A/B testing
- Geo-aware redirects
- Image transformation
- Short-lived stateful flows (a few seconds max)
What does not work on CDN functions: long-lived TCP connections, large memory footprints, anything that needs more than 128MB of RAM.
The reference architecture is to keep your application origin in a single region and use CDN functions as a smart reverse proxy. State stays where it has always lived; the edge becomes a fast first hop.
Regional PoPs
For applications that need a real database read on the hot path, regional PoPs are the answer. AWS Local Zones, Azure Edge Zones, and Google Distributed Cloud all offer this. The pattern is:
1. Replicate your primary database to a regional read replica with sub-second replication lag 2. Deploy your application code to the regional PoP, pointing at the local replica 3. Use the central region only for writes and consistency-critical operations
The latency win is real (20-30ms vs 100-200ms) but you pay for it in operational complexity. Multi-region replication is one of the highest-incidence sources of production bugs in any data system.
Device edge
Phones, cars, IoT gateways, edge servers in retail stores. The pattern here is fundamentally different: you cannot push updates atomically, connectivity is intermittent, and compute is constrained.
The reference architecture is to ship a "core" application that runs locally, plus a "sync" layer that reconciles state when connectivity is available. Conflict resolution becomes a first-class concern, not an edge case. CRDTs (conflict-free replicated data types) are the most common primitive because they make merging deterministic without coordination.
The team that ships a reliable device-edge system spends more time on conflict resolution and sync than on the application logic itself. Plan accordingly.
The cross-cutting concern: observability
Edge systems break in different ways than centralized systems. The same user request may take three different code paths depending on which POP serves them. Logs at the edge are partial; you need a way to correlate a user's session across the edge and origin.
The non-negotiable observability primitives for edge systems: structured request IDs propagated through every hop, sampled full-payload logs at the edge, and aggregated metrics that roll up across POPs. Without these, debugging a production edge incident is guesswork.