Edge Computing & CDNs

Cloudflare, edge functions, and pushing compute close to users. The new layer in the stack.

Why Edge Matters in 2026

Traditionally, your app ran in one cloud region. Users in Sydney calling a server in Virginia waited ~250ms just for the round trip — before any work happened. Add TLS handshakes, app processing, database queries, and you're at 800ms+ for trivial requests.

CDNs have long served static content from edge locations near users. New: edge COMPUTE — running code at hundreds of locations globally, milliseconds from any user.

Why this matters:
• User experience — sub-100ms response times globally
• Cost — less origin traffic, less compute in expensive cloud regions
• Resilience — distributed origin = no single point of failure
• Privacy / compliance — process data in the user's region

The edge isn't replacing your origin servers. It's a new layer in front of them. Some workloads belong entirely at the edge; some entirely at the origin; many split intelligently between.

CDN Basics — The Foundation

A CDN (Content Delivery Network) caches static content at edge locations.

The flow:

User in Sydney requests image.jpg
     │
     ▼
DNS → CDN edge (Sydney)
     │
     ├─ Cache hit → serve from edge (10ms)
     │
     └─ Cache miss → fetch from origin (250ms first time)
                      then cache at edge for next requests

Common CDNs:
• Cloudflare — most popular, generous free tier, easy setup
• Fastly — performance-focused, popular with high-traffic sites
• AWS CloudFront — integrates with AWS services
• GCP Cloud CDN — for GCP workloads
• Bunny.net, KeyCDN — cheap alternatives

What CDNs cache:
• Images, CSS, JS, video
• HTML responses (with cache headers permitting it)
• API responses (when they're cacheable)

Cache control via headers:

Cache-Control: public, max-age=3600, s-maxage=86400
                       │              │
                       │              └─ CDN cache: 1 day
                       └─ Browser cache: 1 hour

Cache invalidation — when content changes:
• Set short TTLs and accept staleness
• Use versioned URLs (/static/app-v1.2.3.js — never changes; new version = new URL)
• Purge API: tell the CDN to evict specific URLs

The most reliable pattern: VERSIONED IMMUTABLE URLs for static assets, short TTLs for HTML.

Edge Compute — Cloudflare Workers

Cloudflare Workers run JavaScript/TypeScript code at every Cloudflare edge location (300+ globally). Cold starts under 5ms. Pay per invocation.

A simple Worker:

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    
    // Authentication at the edge
    const authHeader = request.headers.get('Authorization');
    if (!authHeader) {
      return new Response('Unauthorized', { status: 401 });
    }
    
    // Modify or augment requests
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Powered-By', 'Edge');
    return newResponse;
  }
};

Use cases that win at the edge:
• Authentication / authorization (validate JWT, redirect if invalid)
• A/B testing (decide variant based on user)
• Personalization (geo-aware content)
• Image optimization (resize on-the-fly)
• Rate limiting (per IP, per user)
• Bot detection
• Header rewriting

Cloudflare Workers ecosystem:
• Workers KV — eventually-consistent global key-value store
• Durable Objects — strongly-consistent storage with locality
• R2 — S3-compatible object storage with no egress fees
• D1 — SQLite at the edge
• Workers AI — AI inference at the edge

Other edge platforms:
• Vercel Edge Functions
• Netlify Edge Functions
• AWS Lambda@Edge — older, less performant
• Deno Deploy — TypeScript-native

Architectural Patterns

Three common patterns combining edge and origin:

1. Edge as gateway

User → Edge (auth, rate limit, route) → Origin

Edge handles cross-cutting concerns. Origin handles business logic. Best for traditional web apps wanting global reach.

2. Edge-first

User → Edge (entire app logic) → Edge KV / D1 (data)
                                  ↓ (when needed)
                                  Origin database

The whole app runs at the edge. Origin only for things requiring strong consistency (payments, financial state). Best for content sites, marketing sites, simple SaaS.

3. Hybrid

User → Edge (caching, static, auth)
        ↓
        Origin (dynamic logic)
        ↓
        Distributed DB or origin DB

Most modern apps. Edge for speed, origin for complexity.

Trade-offs:
• Edge has limited execution time (10-100ms typical)
• Edge has limited memory (128 MB typical)
• Edge can't reach private cloud resources directly without VPN/tunnel
• Edge databases are simpler than full Postgres/MySQL

Real-World Setup

A modern web app's network path in 2026:

User
  │
  ▼
DNS (Cloudflare/Route53) — anycast, fast resolution
  │
  ▼
Cloudflare edge (Workers + cache)
  │ - TLS termination
  │ - Bot mitigation
  │ - DDoS protection
  │ - Auth check (JWT validation)
  │ - Cache for cacheable responses
  │ - A/B testing
  │
  ▼
Origin load balancer (cloud-native: ALB, GCP HTTPS LB)
  │
  ▼
App instances (containers, Lambda, etc.)
  │
  ▼
Database / cache (RDS, Redis, etc.)

The edge layer cuts response time, blocks attacks, and reduces origin load. The origin handles business logic that needs full power.

For someone building a new app today:
• Cloudflare in front of your origin (free tier covers most needs)
• Static assets via CDN (years-old standard practice)
• Edge auth check (Workers — adds milliseconds, saves origin load)
• Workers for true edge use cases (image transforms, regional routing, A/B tests)

The edge isn't optional anymore — it's a competitive advantage when done right and a missed opportunity when ignored.

Closing the Series

We've covered the full DevOps and Cloud lifecycle:

• Foundations — Linux, networking, shell, Git
• CI/CD — fast feedback loops, automated quality gates
• Containers and orchestration — Docker, Kubernetes
• Cloud — IaaS, PaaS, AWS, GCP, networking
• Infrastructure as Code — Terraform, Pulumi, Ansible
• Observability — metrics, logs, traces, SRE
• Security — DevSecOps, secrets, cloud posture
• Operations — deployment strategies, incidents, DR, FinOps
• Modern practices — GitOps, platform engineering, edge

You've now seen the whole spectrum. No team uses everything; every team should know everything exists.

The honest summary of what to focus on:
• If you're new — Linux, Docker, Git, one cloud, basic CI/CD. That's months of work.
• If you're experienced — pick what your current job actually needs. Going wide-but-shallow on cloud topics often beats going deep on one.
• If you're senior — observability and security are where most teams under-invest. They pay back forever.

The DevOps field changes constantly, but the FUNDAMENTALS don't:
• Automate things you do twice
• Versions everything in code
• Make the right thing the easy thing
• Test your assumptions
• Measure what matters
• Be kind to on-call

Good luck. Build great systems. Sleep well.