Stackbook Logo
scalingestablished · medium operational burden

Edge Computing

Also known as: edge-functions, compute-at-the-edge

Intent

Run computation and caching close to users or devices to cut latency and offload origin systems.

Problem

Requests that travel to a distant origin pay round-trip latency and load central infrastructure. Some workloads, such as personalization checks or device data filtering, need decisions within milliseconds.

Forces

  • •Network distance dominates latency
  • •Edge runtimes are constrained in memory, time, and APIs
  • •State is hard to keep consistent across many locations
  • •Origin capacity and egress cost are limited

Solution

Overview

Edge computing moves work from a central region to points of presence near users. Common uses range from CDN caching to running small functions on every request and, in IoT, processing sensor data near the device.

Edge platforms differ in runtime model. Some run lightweight isolates with strict CPU limits and no filesystem. Others run containers near cell towers or on-premises gateways. Check limits on execution time, memory, outbound connections, and available storage before designing around them.

How it works

The edge handles what it can and forwards the rest.

client -> edge node
  1 verify JWT signature (no origin call)
  2 cache lookup (key: path + variant)
  3 hit  -> respond
    miss -> origin -> store with TTL 60s, stale-while-revalidate
  4 origin down -> serve stale

For data, favor read-mostly patterns. Replicated key-value stores at the edge are eventually consistent, so use them for configuration, feature flags, and catalogs, and send writes to the origin. Use request collapsing so that simultaneous misses result in a single origin fetch.

Pitfalls

  • Storing mutable state at the edge without a consistency plan
  • Deploying edge code with no staged rollout, so one bug hits all locations
  • Cache keys that include cookies and destroy hit ratio
  • Using proprietary APIs everywhere, making migration expensive

Key takeaways

  • Keep edge logic stateless and small
  • Serve stale on origin failure to improve resilience
  • Roll out edge code gradually
  • Design cache keys carefully

✓ When to Use

  • •Latency-sensitive global traffic
  • •Cacheable or lightly personalized responses
  • •Filtering or aggregating device data before upload

✗ When Not to Use

  • •Logic needs strongly consistent central state
  • •Heavy compute exceeding edge runtime limits
  • •Traffic is concentrated in one region near the origin

Pros

  • +Lower latency and origin load
  • +Absorbs traffic spikes and abuse early
  • +Improves resilience to origin slowness

Cons

  • −Limited runtimes and debugging tools
  • −Stale data risk at the edge
  • −Vendor-specific platforms increase lock-in

Cost Profile

Infrastructure

Medium - per-request edge pricing

Operational

Medium

Cognitive

Medium

Failure Modes

  • Stale cached content served after an update

  • Edge logic bug deployed globally within seconds

  • Origin overload when cache misses stampede

Real-World Examples

Alternatives

    Related Patterns

    • caching
    • load-balancing

    Competency Domains

    distribution communicationdata state