State at the Edge

The Fundamental Tension

 edge compute runs in 300 places. databases of record run in few.

 every POP holding live state = consistency nightmare;
 centralizing all state = latency returns, edge advantage dies.

 the entire discipline is choosing WHAT state goes WHERE:
 
 ┌─────────────┬──────────────────────────────────────────┐
 │ replicated  │ read-heavy shared data (KV, config)      │
 │ to edges    │ staleness tolerated by design            │
 ├─────────────┼──────────────────────────────────────────┤
 │ cached      │ derived views with TTLs                  │
 │ at edges    │ misses fall through to regions           │
 ├─────────────┼──────────────────────────────────────────┤
 │ single-owner│ strongly-consistent entities (actors)    │
 │ at an edge  │ one POP owns; requests route to owner    │
 ├─────────────┼──────────────────────────────────────────┤
 │ regional    │ system of record (databases, money)      │
 │ (of record) │ edges are clients, never authorities     │
 └─────────────┴──────────────────────────────────────────┘

Layer 1: Replicated Edge KV

 platform KV stores: write → primary region → replicate outward

 reads at any POP:     ~1ms (local copy)
 writes:               ~100-300ms (round trip to region)
 consistency:          EVENTUAL — other POPs see it within seconds

 right for: feature flags, rate-limit configs, session metadata,
            routing tables, feature entitlements
 
 wrong for: anything where two writers race meaningfully
            (counters! last-write-wins loses increments)

Layer 2: Durable Objects / Actors — Stateful Islands

 the escape hatch for STRONG consistency at edge latencies:

 object = entity + its state + single-threaded logic,
 assigned to EXACTLY ONE machine fleet-wide:

 class Counter extends DurableObject {
   async increment() { this.state.n++; return this.state.n; }
 }

 all requests for counter#42 → routed to ITS home.
 guarantees per object: serial execution, strong consistency,
 no races. scale comes from MANY independent objects,
 not scaling ONE across machines.

 perfect for: per-room chat state, collaborative docs,
              per-user coordination, rate limiters per key

The Decision Tree

 need cross-entity transactions?        ──► regional database
 single-entity strong consistency?      ──► durable object/actor
 read-mostly shared config?             ──► edge KV
 derived/cached view?                   ──► cache + TTL
 append-only events?                    ──► queue to region

 most real systems use ALL FOUR simultaneously —
 the skill is routing each data type honestly.

Consistency Across Layers

 user updates profile via edge:

 [edge] writes ──► regional DB (truth)
             └──► invalidates/updates KV copies
 subsequent reads:
 - same POP: sees update immediately (local invalidation)
 - other POPs: stale ≤ replication lag (seconds)
 - read-your-writes fix: version stamp in session cookie;
   readers compare + refetch if behind (established pattern)

Interview Framing

“Real-time collaborative editing globally” is the state-at-edge showcase question. Scored architecture: durable-object-per-document owning authoritative state (strong consistency per doc), edge KV for presence/prefs, regional storage as durability backstop, version-stamped reads for cross-POP freshness. Explaining WHY one-owner-actors resolve the tension — serialization without global coordination — is the insight being tested.