Chapter 28: Building on Cloudflare
The mental models that matter and the path forward
The platform decisions in this book come back to three questions: where should work run, who owns each piece of state, and what must remain true when part of the system fails?
The mental models that matter
Partition around the domain
A Durable Object works well when its identity matches a real coordination boundary: a room, session, game or customer quota. A separate D1 database can give a tenant an independent data lifecycle. Neither pattern makes arbitrary partitioning safe. Keep operations that must commit together within a boundary that can provide that guarantee, and plan explicitly for work that crosses it.
The useful question is not simply how to make a component bigger. Ask what must share state, what can progress independently, and whether the partition will remain balanced as the product grows.
Separate global entry from data locality
Workers gives an application a global entry point without a fleet of regional application servers to operate. Its dependencies still have locations. A Durable Object owns state in one place; D1 writes go to a primary; KV trades immediate consistency for distributed reads.
Measure the complete request path. Nearby compute cannot cancel a remote database round trip, and global deployment does not remove the need to plan for dependency failures or residency obligations. Placement is a tool for the application's latency and data requirements, not a promise that everything runs everywhere.
Compose around guarantees
Bindings make platform services straightforward to connect. Architecture is choosing which service owns a decision, which calls can be retried and which failures the caller must handle. Use a queue when work needs independent delivery and retry; use a workflow when progress between steps must survive failure; use an object when concurrent actions need one authority.
Those choices should make the system easier to explain. A design that requires every operator to remember an unwritten exception is carrying a cost that will surface during an incident.
The trade-offs worth remembering
Workers' CPU meter excludes I/O wait. That can make orchestration economical, but the backend calls, data operations and inference still have costs. Model the whole operation rather than treating a cheap Worker invocation as a cheap application.
Small execution and storage units encourage partitioning. Their exact limits can change; the need to choose sensible boundaries remains. When a workload needs a large shared transactional database, retaining PostgreSQL or MySQL behind Hyperdrive may be the right design.
Durable Objects can simplify coordination by combining an actor with storage and routing. That combination is also an architectural commitment. Understand how you would reconstruct its concurrency, lifecycle and connection behaviour elsewhere before placing it at the centre of the product.
AI model choice belongs to the workload. Evaluate quality, latency, cost and failure behaviour using representative tasks. Keep Workers AI when it meets those requirements, and use other providers where it does not. A common gateway can make that choice easier to operate without making the models interchangeable.
The next decision
For a new system, prototype the operation with the hardest consistency or latency requirement. Exercise its failure path as well as its happy path. Measure from the users' locations, price it at expected volume, and confirm that the team can diagnose it.
For a migration, move one boundary at a time. Establish a baseline and a rollback that preserves state, then measure what improved and what became harder. Keep a hybrid design when it gives the workload a better home; completing a platform migration is not a product outcome by itself.
If the fit is poor, choose another platform for that part of the system. The evidence that lets you reject a design is as useful as the evidence that lets you commit to it.
The opportunity
Cloudflare makes global request handling and stateful coordination accessible through a small set of primitives. The opportunity is to use those primitives where they remove work you would otherwise have to build and operate, while accepting the constraints they introduce.
This book has aimed to help you recognise that fit before committing. The next step is to turn the judgement into a running system, test the assumptions and revise the design when the evidence calls for it.
Now build.