An edge layer can accept a browser request quickly while the authoritative write still occurs elsewhere. A fast acknowledgment before the origin commits creates false success. If the next read comes from an edge cache or lagging replica, the user may see old state after saving. Routing a write to a different region during failover can also duplicate side effects unless the operation has an identity and an authoritative owner. The contract must distinguish accepted, committed, and reflected states, and it must tell clients what to do while a fresh read is unavailable.
Edge-to-Origin Write Routing and Consistency
Working case
Reviewer 47 changes case 29 from open to held. The edge returns 200 before the origin transaction finishes, then a browser reload hits a stale cached case summary and shows open. The reviewer retries, creating two audit entries. The revised path forwards the mutation with a stable idempotency key and waits for an origin commit result or returns an explicit accepted operation with a status resource. The response carries a case version. Subsequent reads use that minimum version, route to the authoritative region, or show a pending state until a replica catches up. A failover cannot silently move ownership and accept the same write twice.
Implementation boundary
function readMeetsWriteVersion(readVersion, committedVersion) {
return Number.isInteger(readVersion) && readVersion >= committedVersion;
}
console.log(readMeetsWriteVersion(47, 48));
// Output: falsePick the authoritative storage region or service for each record. Forward mutating requests to it under a bounded deadline, preserving method, body, and trusted actor scope. Use conditional writes or version checks for concurrent editors and an idempotency key for retryable operations; these solve different problems. Return committed only after durable commit evidence, otherwise use a documented accepted state with a status route. Attach a version to the result and let the next read request or session require at least that version. Bypass stale caches for private post-write reads or revalidate them with the same version. During failover, fence the old writer before a new one accepts writes and replay pending operations by stable identity. Keep audit events consistent with the committed state.
Cost and boundaries
A write routed to a distant owner pays a network round trip, even if the edge receives the browser request nearby. Waiting for a replica to reach version V adds tail latency; reading the owner can cost more per request but yields fresher state. Idempotency records consume O(W) storage for W recent writes within a retention window. Version checks add indexed reads or transaction conditions. Measure commit latency, stale-read duration, duplicate-effect rate, accepted-operation backlog, and failover fencing time. Hiding these costs behind a fast edge 200 only moves the failure into the user workflow.
Failure trace
Delay the origin transaction after the edge receives the request. The edge must not report a committed save before evidence arrives. Drop the origin response after a successful commit and retry with the same idempotency key; the audit log should contain one effect. Route a read through a lagging replica and ensure the UI does not present an older version as final. Fail the owner region mid-write, promote a new owner, and reject writes from the old leader once it returns. Change case permission between edge receipt and origin execution; the origin should deny the stale actor.
Verification
- Committed responses follow durable origin evidence.
- Retries share a stable operation identity and produce one effect.
- Post-write reads do not present older versions as final.
Practice drill
Create case 29 at version 47. Send a held mutation with key review-63, lose the response after commit, then repeat it. Verify one committed version and one audit event. Make the nearest read replica lag by 900 milliseconds and request minimum version 48. Compare waiting, owner-routing, and pending-state designs under a 1.2-second task budget. Simulate failover with two would-be writers and record the fence that prevents both from committing. Remove reviewer access before origin execution and confirm no write occurs.
Decision note
An edge response may be fast, but only the authoritative commit determines whether a write succeeded.
Common Mistakes
- Returning 200 when only a mutation message was queued.
- Treating idempotency and concurrency version checks as the same control.
- Letting two regions accept writes during failover.
Related lessons
Edge Runtime and Origin Boundaries; Edge Request Normalization and Origin Trust; Edge Compute Budgets and Upstream Fanout; Edge Cache Locality, Invalidation, and Private Scope; Conditional Writes and Lost-Update Prevention; Replica Lag, Read-Your-Write, and Version Cursors.
Apply and check
Build Project: edge permit case delivery and review Web Development: edge and origin contracts quiz.
