Guide

Edge computing explained

Harbor Commerce launched in Sydney and Singapore before its US data center was ready. Checkout pages routed every API call to us-east-1, adding 180–240 ms of round-trip latency per request. Cart abandonment in APAC ran 11 points higher than North America. Moving authentication, A/B assignment, and inventory-region routing to edge functions at CDN points of presence (PoPs) cut median API latency from 210 ms to 38 ms for Sydney users — without migrating the full order database out of Virginia. Edge computing runs short-lived code geographically close to the user, on the same anycast network that already caches static assets. This guide explains how edge compute differs from CDN caching and regional cloud, common platforms from Cloudflare Workers to Lambda@Edge, what workloads belong at the edge, a Harbor Commerce geo-routing worked example, an architecture decision table, pitfalls, and a production checklist.

What edge computing means on the web

In cloud architecture, edge computing means executing application logic at distributed edge nodes — servers in hundreds of cities — instead of only in a few centralized regions. The “edge” is relative: farther from the origin data center, closer to the browser or mobile client. Modern edge platforms are usually operated by CDN providers who already terminate TLS and cache static files at PoPs worldwide.

Three layers are easy to confuse:

CDN caching (see CDN explained): stores cacheable HTTP responses at PoPs. No custom code runs; cache keys and TTL headers drive behavior.
Edge compute / edge functions: runs your JavaScript, WASM, or Rust handler on the CDN node before (or instead of) forwarding to origin. Dynamic per-request logic with millisecond-scale cold starts.
Regional cloud (us-east-1, eu-west-1): full VMs, containers, and databases with complete runtime APIs but higher latency to distant users.

Edge compute sits between caching and regional cloud: more flexible than a CDN cache rule, lighter and closer than a cross-ocean round trip to origin.

Why teams adopt edge compute

Latency reduction

Speed of light sets a floor: Sydney to Virginia is ~200 ms round trip before your code runs. Executing token validation or geo routing in Sydney removes that hop. Gains matter most for chatty APIs (mobile apps with dozens of micro-requests) and for improving Core Web Vitals on dynamic HTML at the edge.

Traffic absorption and resilience

Edge handlers can reject abusive requests, enforce rate limits, and serve stale fallbacks before traffic hits a fragile origin. During traffic spikes, PoPs scale horizontally across the CDN’s network rather than overwhelming one regional load balancer.

Data residency and compliance

Some regulations require processing personal data inside a jurisdiction. Edge platforms expose request metadata (cf-ipcountry, city, colo ID) so you route EU citizens to EU origins without storing IP databases yourself. Edge is not a substitute for legal review — but it is a routing primitive.

Operational simplicity for cross-cutting concerns

Auth cookie parsing, bot detection, canonical redirects, and feature-flag assignment are identical on every route. Running them once at the edge avoids duplicating middleware in twelve microservices.

Major edge platforms and execution models

Cloudflare Workers

V8 isolates run JavaScript/WebAssembly on every Cloudflare PoP. No containers; sub-millisecond cold starts; tight CPU and memory limits per request. Workers bind to KV, D1 (SQLite), R2 object storage, and Durable Objects for state. Popular for middleware, API gateways, and lightweight BFF layers.

AWS Lambda@Edge and CloudFront Functions

Lambda@Edge runs Node.js or Python on CloudFront PoPs with higher limits but slower cold starts than Workers. CloudFront Functions are ultra-light JS for header manipulation only. Fits teams already on AWS who want edge hooks without a second vendor.

Vercel Edge Middleware and Netlify Edge Functions

Framework-integrated edge runtimes for Next.js, Remix, and static sites. Ideal when edge logic is tightly coupled to page routing (geo redirects, auth gating on SSR). Less general-purpose than Workers but faster to ship for frontend teams.

Fastly Compute and Akamai EdgeWorkers

WASM-first edge runtimes targeting performance-sensitive CDN customers. Strong when you already pay for enterprise CDN contracts and need programmable caching plus compute on the same PoP.

All platforms share constraints: short CPU time budgets, limited filesystem, no arbitrary background threads, and vendor-specific APIs for storage. Design for serverless semantics — stateless handlers, external stores for persistence.

What belongs at the edge (and what does not)

Good edge workloads:

JWT or session cookie validation before origin
Geo-based redirects and locale selection
A/B test bucketing and feature-flag evaluation
HTML rewriting, security headers, and bot scoring
Aggregating responses from multiple origin APIs (light BFF)
Serving cached JSON with short TTL and stale-while-revalidate

Poor edge fits:

Heavy database transactions or long-running batch jobs
Large file transforms (video transcoding, ML inference on big tensors)
Strong consistency requirements across writes (use regional DB + edge read cache)
WebSocket sessions that need minutes of sticky state without Durable Objects
Compliance workloads needing audited hardware in a specific building

The rule of thumb: if it finishes in <50 ms of CPU, touches no large dataset, and tolerates eventually consistent reads, edge is worth evaluating.

Harbor Commerce: APAC geo-routing middleware

Harbor’s storefront stack: Next.js on Vercel (origin), Postgres order DB in us-east-1, inventory API in the same region. APAC launch requirements:

Edge middleware (Vercel Edge): reads x-vercel-ip-country, sets x-harbor-region header (apac | amer | emea).
Auth at edge: validates session JWT signature with a cached public key in edge config — rejects expired tokens with 401 before SSR work begins.
Inventory read path: edge handler fetches stock from a Cloudflare KV replica synced every 30 s from origin; stale reads acceptable for “in stock” badges.
Checkout writes: always proxy to us-east-1 — edge never commits orders locally.
Observability: edge logs ship to the same OpenTelemetry collector with deployment.environment=edge attribute for separate SLO dashboards.

Result: Sydney median TTFB on product pages dropped from 420 ms to 190 ms; APAC cart abandonment gap narrowed from 11 points to 3 points over six weeks. Origin load fell 18% because bots and expired sessions never reached Postgres connection pools.

Architecture decision table

Requirement	Prefer	Why
Static assets, immutable files	CDN cache only	Cheapest; no compute cost at PoP
Per-request auth, redirects, headers	Edge function	Latency win; blocks bad traffic early
Complex business logic + ACID writes	Regional origin service	Full runtime, transactions, easier debugging
Global read-heavy API with tolerated staleness	Edge + replicated cache (KV/CDN)	Serves reads locally; async sync from origin
Long-running jobs, cron, queues	Regional worker / container	Edge CPU timeouts prohibit batch work
Multi-cloud portability	WASM module + abstraction layer	Same handler on Workers, Fastly Compute, local dev

Common pitfalls

Treating edge as a full backend. Pushing order creation to edge without transactional storage creates split-brain inventory.
Ignoring cache invalidation. Edge KV replicas drift; define max staleness and user-visible fallback copy.
Vendor API lock-in. Cloudflare KV does not port to Lambda@Edge. Abstract storage behind interfaces if multi-cloud matters.
Debugging blind spots. Reproduce edge bugs with wrangler dev / local mimics; production-only geo issues are painful.
Secret sprawl. API keys in edge env vars replicate to every PoP; rotate often and scope permissions tightly.
CPU limit surprises. JSON parsing a 5 MB payload at edge times out; enforce size limits at CDN.
Assuming linear cost savings. Per-invocation edge pricing adds up on high-QPS endpoints; model monthly bill before migration.

Production checklist

Measure baseline latency per geography (RUM) before moving logic edge-ward.
Classify endpoints: read vs write, staleness tolerance, CPU budget.
Keep writes and authoritative state on regional origin unless using purpose-built edge databases (Durable Objects, etc.).
Implement auth and rate limiting at edge for defense in depth.
Version edge deployments separately from origin; canary by colo or percentage.
Log with trace IDs propagated to origin for end-to-end distributed tracing.
Test from multiple regions with VPN or synthetic monitoring probes.
Document data-flow diagrams for compliance (where PII is parsed and stored).
Set alerts on edge error rates distinct from origin 5xx.
Re-evaluate quarterly: edge pricing and limits change; origin latency may improve with new regions.

Key takeaways

Edge compute runs code at CDN PoPs — closer to users than regional cloud, more flexible than static caching.
Best for short, stateless middleware — auth, routing, flags, and light aggregation.
Keep authoritative data at origin — replicate reads to edge caches when staleness is acceptable.
Platform choice follows your stack — Workers for general edge, framework middleware for SSR apps, Lambda@Edge for AWS shops.
Measure per-region outcomes — edge helps APAC more than users already near your data center.