The cover illustrates a fictional store, not a deployed system or real test result.
The website opens faster from another country, but order confirmation still waits on a database in a different region. At fictional Ready Parts, I would not move everything to the edge just because it is closer to customers. First map where each task’s data and decision point are. Several network round trips can cost more time than proximity saves.
Edge and serverless can make some work easier to place and operate, but answer different questions. Edge concerns where work runs near users or networks. Serverless describes a model in which a provider takes on some resource-allocation work. Choose by journey, correctness, limits, and cost; neither label proves unlimited scale.
Place work near the data or service it needs
Product images and public descriptions fit a cache near readers. Request validation or routing may happen before the origin. But an order that must make several calls to the primary database needs an assessment of data location and round trips. Compute near the customer does not move a database on another continent with it.
If a new edge gateway still calls the same app, which calls the same database in the same sequence, measure whether the added layer removes work or simply adds another network hop. Repeating authorization may have a reason, but its boundaries and handoff must prevent a direct origin call from bypassing checks.
Where code runs and where data is consistent are separate questions; multiple caches can help shared reads, while a decision requiring one agreed state, such as who reserves the last unit, needs coordination rules and a suitable data source.
Public reads and allowed caches
Transactions needing coordinated state
Check distance and API or model quotas
Serverless reduces some operations work; it does not remove system limits
The provider may manage machines, environment isolation, and scaling compute units. Developers still own code, service dependencies, access, data, and behavior at limits. Billing may depend on requests, time, CPU duration, execution time, or other product resources. Read the actual billing unit before calculating cost.
Example:Cloudflare Workers documentation distinguishes CPU time from time waiting on I/O and sets bounds for memory and outbound calls. It shows why “duration” must be read in a product’s context. Do not transfer one service’s limits to another or assume network waiting is free under every charge.
Even when a platform scales compute, downstream services can fill up: a small database pool, a partner API quota, or an overloaded AI service. Bound concurrency and total wait time. Do not let calls growing with load strike an uncapped destination.
Startup behavior also depends on runtime and product. Do not promise that every serverless option lacks a cold start, or assume data kept in memory lasts forever. Durable work needs appropriate storage, with deployment of new versions and platform work migration considered.
Durable Objects can coordinate state within a defined boundary
Cloudflare Durable Objects are an example of combining code with an identifiable object’s state. Each object has its own data boundary and storage that supports the documented consistency model. Consider it for a coordination point such as one chat room or genuinely separable business-unit state, not as a reason to turn every database into objects.
Independent objects can distribute independent work. But if every store request goes to one object, the hotspot remains. “Scale out” does not mean one key can handle unlimited work. The documentation has per-object limits, and throughput still depends on what the object does. This article does not turn a provider soft limit into a store-capacity guarantee.
Single-threaded does not eliminate logical races when work interleaves around asynchronous I/O. Consistency within one object’s storage does not create one atomic transaction across every object and external database. Reserving several items requires identifying the invariants that must hold together before splitting keys.
Separate independent state across objects
One joint rule still needs coordination
Adding other keys does not fix one busy key
If the key is per customer but the rule concerns the last unit in one warehouse, all customers still contend over that unit. Splitting into many objects without preserving the rule could oversell stock. Conversely, independent rooms or branch stores may fit separate objects better than routing everyone through one coordinator.
Use AI where it helps, without blocking every purchase on it
The fictional store might offer a parts-manual assistant, but every product view need not call a model. Separate AI used to help write code or prepare content ahead of time from inference that runs while a customer waits. The latter adds a dependency, latency, quotas, and per-use cost. We need a reason the customer benefits beyond what ordinary search can provide.
Putting a gateway at the edge does not put an external model beside every user. If inference or document search happens in another region, distance and round trips remain. Measure from the start of the user task to a usable answer, including context retrieval, authorization filtering, and output checking, not just time to first token.
A model answer alone should not confirm price, stock, or payment. Retrieve authorized values from the source of record and apply deterministic checks suited to the task. When the model cannot answer, send the person to source search or staff help instead of inventing a part number or expressing confidence beyond the evidence.
Control AI budgets and access like any resource-using service
Limit input size, concurrent work, wait time, and budget by an appropriate user or department. Keep private information and documents the user cannot read out of context. Separate permission to read from permission to trigger an action. If the model can call tools, authorize them and confirm business-impacting outcomes according to risk.
Do not cache an account-specific answer for everyone. AI-output storage needs the same attention to access, document version, and freshness as any cache. New documents can invalidate an old answer, and similar questions may come from people with different rights. Reuse needs explainable, testable conditions.
| Work | Options to compare | Condition to preserve |
|---|---|---|
| Public images and pages | Prepare ahead and cache near readers | No private data; update content under clear rules |
| Order confirmation | Near data needed for a shared decision | Transactions, access rights, and no duplicate outcome |
| Coordinate state within a boundary | Keyed or object-based service when work is truly separable | Do not discard a shared invariant across keys |
| Search manuals with AI | Keep off the required purchase path | Data rights, budget, quota, result checks, and fallback |
Measure an option before binding the entire system to it
Begin with a separable, reversible journey. Measure user-visible latency, downstream call cost, errors, and operating effort. Test an unavailable downstream service, a very hot key, and an exhausted quota. A test only of easily distributed work misses the store’s hardest question.
Check data export, API formats, and the team’s time to move platforms. A managed service has value in work the team avoids, but also learning costs and product-specific dependencies. Reversibility need not mean a same-day provider switch, but it should have a realistic plan and visible cost.
Data location and observability belong in the design
Compute in several regions does not by itself say where personal data is stored, transferred, or logged. Trace the path from browser through gateway to database, model, and monitoring, against contracts and requirements the business must meet. “Edge” is not a data-residency guarantee.
Use trace IDs to connect stages without putting secrets in URLs or logging more user text than needed. Where services have separate clocks, measure network waits and processing time in a comparable way. One platform’s graph may miss the other service where customers spend most of their time waiting.
When testing a new option, provide a real fallback, such as keyword manual search in place of AI, or a status check against the order source of record. Do not return unauthorized stale data merely to have an answer. Test the fallback’s permissions, capacity, and clarity for users; it should not be a sentence buried in a document that nobody has tried.
Rights, context, size, and need
Concurrency, time, quota, and cost
Check source values; offer search or help
I would place work near users when it truly removes needed travel, use a coordination service when the data boundary is clear, and add AI when user benefit justifies waiting and cost. The store’s core tasks still need a path to completion when an add-on is unavailable.
Provider documents cited here were checked on October 18, 2026. Limits, plans, and billing can change; the team must verify the version and terms actually in use before implementation. The next episode brings request counts, compute time, operating work, and retries into cost per transaction to see whether growth improves value or merely grows the bill.
Read the sources and limits of the example
The following sources explain the concepts and limitations and were checked on October 18, 2026. The fictional store numbers and choices are my synthesis, not provider prices, test results, or guarantees. Check the current version, plan, and terms before applying them.