![Edge Computing Use Cases: 7 Real Deployments [Solved]](/images/blog/edge-computing-use-cases-7-real-deployments-solved.jpg)
Edge computing moves workloads closer to users. In theory, latency drops and origin load decreases. In practice, misconfigurations turn edge nodes into bottlenecks or cache-miss machines that hammer your origin harder than before.
I've debugged dozens of edge rollouts where latency actually increased post-deployment. This guide walks through seven real production scenarios—CDN cache poisoning, broken origin shielding, DNS steering failures, and more. Each section shows symptoms, root cause, and the exact fix.
1. CDN cache miss storm after deploying edge workers
Symptoms
Origin CPU spikes to 90% within minutes of enabling the edge worker. Cache hit ratio drops from 85% to 12%. Response times jump from 120ms to 3 seconds.
Root cause
The edge worker modifies request headers before cache lookup. Even minor changes—adding X-Custom-Id or normalizing User-Agent—create unique cache keys. Every variant misses cache and hits origin.
In one case, a worker added a request ID to every inbound request. The CDN treated each ID as a distinct object. Tens of thousands of users meant tens of thousands of origin requests per minute.
The fix
Move header manipulation to after cache lookup, or explicitly control cache keys.
For Cloudflare Workers:
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
// Clone and strip custom headers BEFORE cache check
let cacheKey = new Request(request.url, {
method: request.method,
headers: new Headers({
'Host': request.headers.get('Host'),
'Accept-Encoding': request.headers.get('Accept-Encoding')
})
})
let cache = caches.default
let response = await cache.match(cacheKey)
if (!response) {
response = await fetch(request)
event.waitUntil(cache.put(cacheKey, response.clone()))
}
return response
}
Alternatively, use the CDN's cache key API to ignore specific headers. For Cloudflare Page Rules, set "Cache Key" to ignore query strings or headers that don't affect content.
Verify the fix by checking cache analytics. Hit ratio should climb back above 80% within ten minutes.
2. Origin shielding sends traffic to the wrong region
Symptoms
After enabling origin shielding, latency for European users increases by 200ms. Edge logs show requests routing through a US shield node before reaching your EU origin.
Root cause
Most CDNs let you specify one shield location. If your origin is multi-region or anycast, the shield might not be closest to the actual origin instance serving the request.
Another variant: the CDN's shield selection logic uses edge node location, not origin location. A request from Sydney hits the Sydney edge, which contacts the US shield, which contacts your EU origin. Two ocean crossings instead of one.
The fix
Disable global shielding and configure regional shields that match your origin topology.
For a dual-region origin (US-East and EU-West):
CDN Edge (US) → Shield US-East → Origin US-East
CDN Edge (EU) → Shield EU-West → Origin EU-West
CDN Edge (Asia) → Shield US-West → Origin US-East (or nearest)
Cloudflare calls this Tiered Caching with regional splits. Configure it under Caching > Tiered Cache, then set up Load Balancing with geo steering to ensure the right origin answers.
If your CDN doesn't support regional shields, origin-side geo routing is the alternative. Use DNS-based steering (Cloudflare Load Balancer, Route 53 geolocation) to return different origin IPs per continent.
Test with curl from multiple regions:
curl -I https://yourdomain.com -H "CF-IPCountry: DE"
Check the CF-Cache-Status or X-Cache header and the CF-Ray datacenter code. EU requests should hit EU shields.
3. Edge function timeout kills slow API calls
Symptoms
API endpoints that take 8-12 seconds work fine when called directly. Through the edge, they return 524 or 504 after exactly 10 seconds.
Root cause
Edge runtimes enforce strict execution limits. Cloudflare Workers have a 50ms CPU time cap and a 30-second wall-clock timeout on the Free plan, 15 seconds on Workers alone. If your function waits on a slow origin API, the clock runs out.
Worse, some platforms count origin response time against the function's budget. A 10-second database query burns 10 seconds of wall time.
The fix
Don't proxy long-running requests through edge functions. Route them directly to origin.
addEventListener('fetch', event => {
const url = new URL(event.request.url)
// Skip edge logic for slow endpoints
if (url.pathname.startsWith('/api/reports')) {
return event.respondWith(fetch(event.request))
}
event.respondWith(handleFast(event.request))
})
For truly necessary edge processing of slow operations, split the work:
- Edge function accepts the request and returns a 202 Accepted with a job ID.
- Origin worker processes the job asynchronously.
- Client polls a separate edge-cached status endpoint.
Another option is to increase the timeout by moving to a premium edge compute tier. Cloudflare Workers Unbound allows 30-second CPU time and 15-minute wall time. AWS Lambda@Edge supports 30 seconds; CloudFront Functions support only 1 second but are meant for header manipulation, not origin calls.
4. DNS steering ignores latency and routes by geography alone
So what if your multi-region setup is live but users still hit distant nodes?
Symptoms
Users in Singapore connect to the Sydney edge, then route to a Tokyo origin—despite a Singapore origin being available and closer. DNS resolution is geographically correct, but actual latency is worse.
Root cause
Geolocation-based DNS (Route 53 geolocation, Cloudflare Geo Steering) returns the nearest IP by map, not by network path. Peering, congestion, and transit differences mean the geographically nearest node isn't always the fastest.
Additionally, DNS resolvers don't always pass client subnet information (EDNS Client Subnet). The authoritative DNS sees the resolver's IP, not the user's, and returns a result optimized for the resolver's location.
The fix
Switch to latency-based or health-check-informed steering.
For Route 53, use Latency-based routing instead of Geolocation:
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch file://latency-routing.json
latency-routing.json:
{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "api.yourdomain.com",
"Type": "A",
"SetIdentifier": "Singapore",
"Region": "ap-southeast-1",
"TTL": 60,
"ResourceRecords": [{"Value": "192.0.2.10"}]
}
}]
}
Repeat for each region. Route 53 probes latency from its resolvers and directs clients to the fastest.
Cloudflare Load Balancer with dynamic steering does this automatically. It measures health and latency to each pool and routes accordingly.
Verify by querying DNS from multiple locations:
dig api.yourdomain.com @1.1.1.1 +subnet=1.2.3.4/32
The returned IP should match the lowest-latency origin for that subnet.
5. Edge cache serves stale content indefinitely
Symptoms
You deploy new assets (CSS, JS, images). Users continue seeing old versions for hours or days. Purging cache through the CDN dashboard has no effect. Direct origin requests return the new content.
Root cause
Two common culprits:
- Stale-while-revalidate headers set too long. The edge serves stale content and revalidates in the background, but if revalidation fails (origin down, rate limit), stale persists.
- Layered caching without purge propagation. You purge the outer edge, but a regional shield or origin shield still holds the old object and re-populates the edge.
In one case, a Cache-Control: max-age=300, stale-while-revalidate=86400 header kept month-old assets live because the origin returned 503 during a deploy.
The fix
Shorten stale-while-revalidate to a reasonable window (3600 seconds max) and ensure origin returns proper 5xx status only during true failures, not deploys.
Cache-Control: public, max-age=3600, stale-while-revalidate=3600
For critical assets, set stale-if-error to 0:
Cache-Control: public, max-age=3600, stale-if-error=0
If layered caching is the issue, purge all tiers:
# Cloudflare - purge everything
curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"purge_everything":true}'
Or purge by tag/prefix if your CDN supports it. AWS CloudFront requires explicit invalidation:
aws cloudfront create-invalidation \
--distribution-id E1234567890ABC \
--paths "/assets/*"
Alternatively, version asset URLs (app.v2.css instead of app.css) so cache naturally expires.
6. Edge node runs out of memory during traffic spikes
Symptoms
Edge logs show JavaScript execution exceeded memory limits or Worker exceeded memory. Requests fail with 503. The pattern coincides with traffic doubling during a promo.
Root cause
Edge runtimes impose per-request memory caps—Cloudflare Workers limit each invocation to 128 MB. If your function buffers large request or response bodies, aggregates data, or holds objects in memory, a spike in concurrent executions exhausts the limit.
A common mistake is reading the entire request body into a string:
const body = await request.text() // Loads full body into memory
If POST bodies average 5 MB and you have 30 concurrent requests, that's 150 MB across workers—above the budget.
The fix
Stream data instead of buffering it.
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
// Stream request body to origin without reading into memory
return fetch('https://origin.example.com/upload', {
method: request.method,
headers: request.headers,
body: request.body // Pass stream directly
})
}
For response bodies, use response.body stream instead of response.text().
If you must process the body, chunk it:
const reader = request.body.getReader()
let chunk
while (!(chunk = await reader.read()).done) {
// Process chunk.value (Uint8Array)
processChunk(chunk.value)
}
Monitor memory usage in edge logs. Cloudflare Dashboard > Analytics > Workers shows memory per invocation. Keep average usage under 64 MB to leave headroom for spikes.
7. Origin overwhelmed because edge doesn't respect rate limits
Symptoms
Origin CPU and database connections max out. Edge analytics show a 95% cache hit ratio, yet origin receives thousands of requests per second. Logs reveal the same resource requested hundreds of times simultaneously.
Root cause
Cache stampede (thundering herd). When a popular cached object expires, the first request triggers a cache miss. Before origin responds, 500 more requests arrive—all miss cache because the object isn't back yet—and all hit origin simultaneously.
Edge platforms without request coalescing or cache locking can amplify this. Each edge node independently fetches the expired object, multiplying load by the number of nodes.
The fix
Enable request coalescing or cache locking at the edge. Cloudflare does this automatically (request collapsing). For platforms that don't, implement application-level locking.
Using Workers KV as a lock:
async function fetchWithLock(url, cache) {
const lockKey = `lock:${url}`
const isLocked = await KV.get(lockKey)
if (isLocked) {
// Another worker is fetching; wait and retry
await sleep(100)
return cache.match(url) || fetchWithLock(url, cache)
}
// Acquire lock
await KV.put(lockKey, '1', {expirationTtl: 10})
const response = await fetch(url)
await cache.put(url, response.clone())
// Release lock
await KV.delete(lockKey)
return response
}
At the origin, implement rate limiting per edge node IP if your platform doesn't coalesce. Nginx example:
limit_req_zone $binary_remote_addr zone=edge:10m rate=50r/s;
server {
location /api/ {
limit_req zone=edge burst=20 nodelay;
proxy_pass http://backend;
}
}
Monitor origin request rate versus edge traffic. A properly configured edge should send 5-10% of edge requests to origin. If the ratio is higher, cache TTLs are too short or edge isn't caching.
Check edge analytics first, always
When edge deployments fail, the edge logs and analytics tell you exactly what broke. Don't guess.
Cloudflare Dashboard > Analytics > Traffic shows cache ratio, bandwidth saved, and requests by status code. A sudden drop in cache hits or spike in 5xx errors points directly to the culprit. Workers > your-worker > Metrics shows invocations, errors, and CPU time. Correlate spikes with deployment times.
For AWS CloudFront, enable standard logs or real-time logs to S3, then query with Athena:
SELECT date, time, c_ip, cs_uri_stem, sc_status, x_edge_result_type
FROM cloudfront_logs
WHERE x_edge_result_type = 'Miss'
ORDER BY date DESC, time DESC
LIMIT 100;
Filtering by x_edge_result_type = 'Error' shows edge errors; RefreshHit reveals stale-revalidation patterns.
Run a load test before and after the fix. Apache Bench from multiple geos:
ab -n 1000 -c 50 https://yourdomain.com/
Compare Time per request and Failed requests. A working edge should cut mean latency by at least 40% compared to direct-to-origin.
What to check first
Before deploying edge logic, verify cache headers are correct. Test the origin response:
curl -I https://origin.example.com/resource
Look for Cache-Control, Vary, ETag, and Last-Modified. If origin doesn't send cacheable headers, the edge won't cache—no matter how fancy the worker.
After deploy, compare latency and origin load for one hour. If latency didn't drop by at least 30% or origin load didn't decrease, roll back and investigate. Edge isn't magic; it's caching and geography. If your origin is slow or your content isn't cacheable, the edge just moves the problem closer to users.
Most edge failures come from misunderstanding cache semantics. Read your CDN's cache behavior docs cover to cover. The 20 minutes spent reading saves days of firefighting production outages.