Edge Computing Patterns: Place Compute Around Latency and State

Decide between CDN, regional and device-edge processing using a latency worksheet, current runtime boundaries and an offline inventory-conflict example.

Move the part that is actually slow

Putting a function near a user does not put its database there. An edge function that calls a distant database for every request may retain most of the original latency while adding a new operational boundary.

Start with a named operation and a user-visible objective. For a catalog page, the acceptable result might be a recent product description. For an inventory reservation, it may require an authoritative decision about the last unit. These are different placement problems even when both are exposed through the same website.

Physical distance contributes propagation delay. Routing, connection setup, queueing, processing and payload transfer add more. City-to-city straight-line distance is not an internet route, and vacuum light speed is not fiber propagation speed. Use observed end-to-end distributions for your users and workload rather than a purported universal “edge latency.”

Choose a location and its operating obligations

| Location | Useful when | Added duty | | --- | --- | --- | | CDN edge | Cacheable responses, request routing or bounded request checks can finish near the user. | Correct cache keys, private-data isolation, invalidation and runtime limits. | | Regional service | Stateful work needs nearby data authority and service capacity. | Regional data placement, failover, write ownership and recovery tests. | | Site or device edge | A local operation must continue through a wide-area outage. | Local durability, physical security, fleet updates and later state repair. |

Browser execution is another option for presentation or computation on data the user may access. The browser is not a trusted place to hold server secrets or enforce authoritative business permissions.

A device-edge installation is not interchangeable with a CDN function. It may run for long periods without connectivity, accumulate data on disk and need a signed update process. For safety-critical control, placement is only one part of the safety design; a general cloud architecture guide cannot establish that a local inference loop is safe.

Use a trace before a regional expansion

The following worksheet describes illustrative timings for a small catalog response. They are not provider benchmarks. Network entries include request and response travel for that segment; local work is listed separately. Connection setup, payload size and cache state must be controlled when reproducing the comparison.

| Candidate path | Components in one trace | Total | | --- | --- | --- | | Client to central service | 120 ms network + 35 ms processing | 155 ms | | Client to edge, then central service | 20 ms nearby network + 5 ms edge work + 95 ms central hop + 35 ms processing | 155 ms | | Client to edge with usable cached data | 20 ms nearby network + 5 ms edge work + 2 ms cache work | 27 ms |

Moving the request handler alone did not improve this example. Avoiding the central round trip did. But the cache-hit path is valid only when its freshness and authorization contract fits the operation.

Do not sum stage p95 values and label the answer an end-to-end p95. Collect full request traces and calculate the percentile on total durations. Keep cache hits, misses, cold execution, geography and error responses visible. A fast failure should not count as a successful latency improvement.

For another illustrative check, imagine 100 requests: 90 take 25 ms and 10 take 175 ms. The mean is 40 ms, while the nearest-rank p95 is 175 ms. A high hit rate can improve the average without fixing the slow experience. These invented observations demonstrate the calculation; they are not measured results.

Verify the named runtime instead of assuming “edge limits”

Documentation checked in September 2026 shows why a single universal runtime checklist is misleading:

• Cloudflare Workers TCP sockets support outbound TCP through the runtime's connection API, including database protocols. That does not promise a durable connection across independent invocations or remove database distance and connection-management costs.
• AWS Lambda@Edge restrictions include no configuration for access to resources inside a VPC and restrictions on environment variables. Those are Lambda@Edge constraints, not rules for all edge products or ordinary regional Lambda functions.

Before selecting a runtime, verify the specific plan, event type and current documentation for CPU versus elapsed duration, memory, request size, languages, outbound networking, connection lifecycle and storage. Also test secrets delivery, logs, rollout visibility and rollback. A language compiling to WebAssembly does not establish that every required library or system call will work.

Keep request authentication and authorization distinct. A valid token can establish claims, but permissions may have changed since it was issued. Define the acceptable revocation delay and which operations require current authoritative authorization. Include that lookup in the latency model.

Make consistency a per-operation decision

A globally replicated database is not a single consistency promise. For example, DynamoDB global tables currently offer multi-Region eventual consistency (MREC) and multi-Region strong consistency (MRSC). MREC resolves concurrent updates to an item using last-writer-wins. MRSC has a three-Region deployment requirement, using three replicas or two replicas and a witness, within supported Region sets. Its constraints differ from MREC, including lack of transaction-operation support. Verify the current mode and supported regions rather than applying a service-wide label.

The design still needs a business conflict rule. Two offline stores each see one remaining unit and each accept one reservation. Later synchronization can make both replicas agree that two reservations exist, but it cannot make one physical unit satisfy both. A convergent data structure does not automatically preserve a stock or spending limit.

A deliberately restricted offline policy could allocate one reservation right to store A and none to store B. A can accept one; B must show availability as unconfirmed and defer acceptance. Rights must not be duplicated during allocation or failover. This sacrifices some availability to preserve the stock invariant.

Define reconnect behavior before enabling offline writes

| Reconnect state | Decision | Unsafe shortcut | | --- | --- | --- | | The same command arrives twice | Ignore repeats by stable command ID within its retention contract. | Treat a new network delivery as a new purchase. | | Two valid commands conflict | Apply the agreed priority, rejection, refund or other repair rule. | Use the latest device clock as proof of business priority. | | Local storage is full | Stop accepting work or use an approved loss policy. | Confirm durable acceptance before data is durable. | | Access or rules changed offline | Recheck before final acceptance. | Trust an old cached permission without a time limit. |

Event logs preserve evidence, but replay must still validate ordering, duplicate effects and current business rules. As Inria's CRDT research overview explains, convergence relies on defined mathematical properties of the data type. That does not decide which customer receives scarce stock. For operations without a safe offline policy, make the limitation visible in the product.

Run a placement experiment with an exit condition

Choose one operation and record the baseline environment, target user locations, successful-response p50/p95/p99, error rate, payload size and cost per completed operation. Run the candidate with realistic cache misses and dependency delay, then test its outage behavior separately.

Agree the acceptance condition before looking at the results. It should cover latency, correctness, stale-data tolerance, security and operating cost. Preserve a tested route back to the original handler and account for data written during the experiment; traffic rollback does not undo those writes.

If most time is spent waiting on authoritative state, review data placement or the workflow before adding another edge runtime. An Ampity cloud architecture engagement can turn that trace and consistency contract into a bounded design decision. Bring one request trace and one offline or failover scenario, not a target number of regions.