Dev Note

The Speed of Light Is Still a Problem
Here’s a physics problem that doesn’t have a software solution: light travels 300km in 1 millisecond. If your user is in Seoul and your nearest data center is in Singapore (~5,000 km away), you’re looking at ~17ms of raw propagation delay — before any processing, before any networking overhead.
For most web apps, that’s fine. For real-time gaming, autonomous vehicles, industrial automation, or AR/VR? That’s disqualifying.
Edge computing brings the computation closer to where data is generated and consumed. In 2026, the edge ecosystem has matured dramatically — there are now clear patterns, platforms, and workloads where edge is the right answer.
Photo by NASA on Unsplash
The Edge Spectrum
“Edge” isn’t a single thing — it’s a spectrum:
Device Edge          Near Edge           Far Edge          Cloud
(IoT sensor,    (Cell tower,        (Regional DC,     (AWS us-east-1,
 car, phone)     factory gateway,     CDN PoP)          GCP asia-east1)
                 retail store)
Latency: <1ms    1-10ms              10-30ms           30-200ms+
Compute: Tiny    Small               Medium            Unlimited
Storage: KB-MB   MB-GB               GB-TB             Unlimited
Understanding where your workload sits on this spectrum determines your platform choices.
When to Use Edge (Decision Framework)
Not everything belongs at the edge. Here’s a practical decision tree:
Does it require <10ms latency?
├── YES → Is connectivity reliable?
│   ├── YES → Near edge or far edge is fine
│   └── NO  → Must run on device edge (offline-capable)
│
└── NO  → Is data locality required (compliance/privacy)?
    ├── YES → Near edge or far edge
    └── NO  → Can data live in cloud?
        ├── YES → Use cloud (simpler!)
        └── NO  → Define why, then reassess
Classic edge use cases in 2026:
Real-time ML inference — fraud detection at point of sale, defect detection in manufacturing
Video processing — license plate recognition, occupancy counting before sending to cloud
Gaming — physics simulation, anti-cheat detection
Autonomous systems — vehicles, drones, robots where cloud round-trip is unsafe
Personalization at scale — A/B testing and feature flags without added latency
Regulatory compliance — GDPR, HIPAA workloads that can’t leave a jurisdiction
Platform Landscape: 2026
CDN Edge (Far Edge)
Best for: Request routing, auth, personalization, caching logic
Platform
      Strengths
      Runtime
      Cold Start
    
Cloudflare Workers
      V8 isolates, global PoPs, Durable Objects
      JS/TS/WASM
      ~0ms
    
AWS Lambda@Edge
      Native AWS integration
      Node.js, Python
      100-1000ms
    
Fastly Compute
      Predictable performance, WASM-first
      WASM (Rust, Go, JS)
      ~0ms
    
Deno Deploy
      Full Deno runtime, TypeScript native
      Deno/TS
      ~0ms
    
Vercel Edge Runtime
      Next.js integration
      Subset of Node.js
      ~0ms
    
Near Edge (Telco / On-Prem)
Best for: Industrial IoT, smart retail, healthcare, manufacturing
AWS Wavelength — compute in 5G carrier networks (~1ms to mobile devices)
Azure Edge Zones — Azure services in carrier networks
MEC (Multi-access Edge Computing) — ETSI standard, carrier-independent
Kubernetes at the Edge — K3s, MicroK8s on-prem clusters
Device Edge
Best for: Offline-first, ultra-low latency, privacy-sensitive
TensorFlow Lite / ONNX Runtime — ML inference on device
WebAssembly — portable compute for constrained environments
ROS 2 — robot operating system
AWS Greengrass — Lambda functions on IoT devices
Building with Cloudflare Workers: A Real Example
Let’s build a real-time personalization layer that runs at the edge:
// workers/personalization.ts
interface Env {
  KV: KVNamespace;
  DO: DurableObjectNamespace;
}
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    const userId = getUserId(request);
    
    // Get user segment from KV (edge-cached)
    const segment = await env.KV.get(`segment:${userId}`, {
      cacheTtl: 60 // cache at edge for 60s
    });
    
    // Fetch origin with personalization context
    const originRequest = new Request(request, {
      headers: {
        ...Object.fromEntries(request.headers),
        'X-User-Segment': segment ?? 'default',
        'X-Edge-Region': request.cf?.region ?? 'unknown',
        'CF-Connecting-IP': request.headers.get('CF-Connecting-IP') ?? ''
      }
    });
    
    const response = await fetch(originRequest);
    
    // Edge-side A/B test: modify response without origin involvement
    if (shouldRunExperiment(userId, 'new-checkout')) {
      return injectExperimentVariant(response, 'checkout-v2');
    }
    
    return response;
  }
};
// Durable Object: stateful edge coordination
export class UserSession {
  private state: DurableObjectState;
  
  constructor(state: DurableObjectState) {
    this.state = state;
  }
  
  async fetch(request: Request): Promise<Response> {
    const events = await this.state.storage.get<Event[]>('events') ?? [];
    
    if (request.method === 'POST') {
      const event = await request.json<Event>();
      events.push({ ...event, timestamp: Date.now() });
      
      // Keep last 100 events
      await this.state.storage.put('events', events.slice(-100));
      
      // Real-time session analytics without round-tripping to cloud
      const analytics = computeSessionAnalytics(events);
      await this.state.storage.put('analytics', analytics);
      
      return new Response(JSON.stringify(analytics));
    }
    
    return new Response(JSON.stringify(events));
  }
}
Edge State with Durable Objects
Durable Objects solve the hardest edge problem: stateful coordination across a distributed system. Each DO is a single-threaded actor that lives at a specific edge location:
// Rate limiting at the edge (no cloud round-trip)
export class RateLimiter {
  private state: DurableObjectState;
  
  async fetch(request: Request): Promise<Response> {
    const now = Date.now();
    const window = Math.floor(now / 1000); // 1-second windows
    
    const key = `rate:${window}`;
    const count = (await this.state.storage.get<number>(key) ?? 0) + 1;
    await this.state.storage.put(key, count);
    
    // Clean up old windows
    await this.state.storage.delete(`rate:${window - 2}`);
    
    const limit = 100; // 100 req/sec
    
    if (count > limit) {
      return new Response('Rate limit exceeded', { 
        status: 429,
        headers: { 'Retry-After': '1' }
      });
    }
    
    return new Response(JSON.stringify({ allowed: true, count, limit }));
  }
}
Edge ML Inference: Practical Patterns
Running ML models at the edge is increasingly viable. Here are the key patterns:
Pattern 1: ONNX Runtime on Device
# Convert PyTorch model to ONNX for edge deployment
import torch
import onnx
import onnxruntime as ort
# Export from PyTorch
model = FraudDetectionModel()
model.load_state_dict(torch.load('model.pth'))
model.eval()
dummy_input = torch.randn(1, 128)  # 128 features
torch.onnx.export(
    model,
    dummy_input,
    "fraud_detection.onnx",
    opset_version=17,
    input_names=['features'],
    output_names=['fraud_score'],
    dynamic_axes={'features': {0: 'batch_size'}}
)
# Optimize for edge
import onnxruntime as ort
session_options = ort.SessionOptions()
session_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL
session_options.intra_op_num_threads = 2  # constrained CPU
session = ort.InferenceSession(
    "fraud_detection.onnx",
    session_options,
    providers=['CPUExecutionProvider']  # or TensorrtExecutionProvider
)
# Inference at edge: typically <5ms
def score_transaction(features: list[float]) -> float:
    import numpy as np
    outputs = session.run(
        ['fraud_score'],
        {'features': np.array([features], dtype=np.float32)}
    )
    return float(outputs[0][0])
Pattern 2: Cascading Edge-Cloud Inference
Don’t run everything at the edge. Use a cascade:
Transaction arrives
      │
      ▼
[Edge: Lightweight model]
  99% confidence? → Decision made at edge (< 2ms)
  < 99% confidence? → Route to cloud
      │
      ▼
[Cloud: Full model + context]
  Decision + model update signal
      │
      ▼
[Edge: Periodic model refresh]
  Download updated edge model
Operational Challenges
Edge adds complexity. Be honest about the costs:
Observability at Scale
With 200+ edge PoPs, traditional centralized logging doesn’t scale. Use:
Sampling — log 1% of requests, 100% of errors
Edge analytics — aggregate at edge, send summaries to cloud
Real User Monitoring (RUM) — client-side telemetry instead of server logs
Deployment Complexity
# Deploying to 200 PoPs is not like deploying to one region
# Use canary deployments with geographic rollout
deployment:
  strategy: canary
  stages:
    - regions: [us-east-1]    # 5% traffic
      duration: 1h
      metrics_threshold: error_rate < 0.1%
    
    - regions: [us-*, eu-*]   # 40% traffic
      duration: 4h
      metrics_threshold: p99_latency < 50ms
    
    - regions: [*]             # 100% global
      duration: immediate
Data Consistency
The CAP theorem hits hard at the edge. Strategies:
Read-your-writes: Route user to same PoP for session duration
Eventual consistency: Accept stale reads for non-critical data
CRDTs: Use conflict-free data structures for distributed state
Cost Model
Edge isn’t always cheaper. A realistic cost comparison:
Workload
      Cloud Cost
      Edge Cost
      Edge Savings
    
10M req/day, simple routing
      $50/mo
      $15/mo
      70% ✅
    
ML inference (1M req/day)
      $800/mo
      $200/mo
      75% ✅
    
Video transcoding (intensive)
      $2,000/mo
      $3,500/mo
      -75% ❌
    
Global state coordination
      $100/mo
      $400/mo
      -300% ❌
    
Rule of thumb: Edge saves money for compute-light, request-heavy workloads. It costs more for compute-heavy workloads that would benefit from cloud’s economies of scale.
Conclusion
Edge computing in 2026 is genuinely useful — but it’s still a specialization, not a default. The platforms (especially Cloudflare Workers and WASM-based runtimes) have made it dramatically more accessible, and the patterns (Durable Objects, ONNX inference, edge auth) are well-established.
Use edge when latency is the bottleneck and physics is working against you. Use cloud when simplicity, compute power, or cost efficiency matters more. The best architectures in 2026 use both — intelligently.
What edge use cases are you working on? I’d love to hear how teams are solving the observability and deployment challenges at scale.

Edge Computing in 2026: When Cloud Is Too Far Away

댓글