Source: https://architectingoncloudflare.com/ # Architecting on Cloudflare Decisions, Trade-offs, and Patterns for the Developer Platform By [Jamie Lord](https://lord.technology) --- ## About this book This book covers Cloudflare's Developer Platform: Workers, Durable Objects, D1, R2, Queues, Workflows, Containers, Realtime for audio and video, and the AI stack including Workers AI, Vectorize, and the Agents SDK. These are the primitives that let you build complete applications on Cloudflare's edge network. Security and networking products appear where they change an application decision. This is not a general guide to Cloudflare's security portfolio; excellent resources already exist for that, written by people with deeper expertise in network security than I possess. This book is for developers and technical decision-makers who want to understand whether Cloudflare's compute, storage, and AI primitives can replace or complement what they're building on AWS, Azure, or GCP. If you're evaluating serverless platforms, designing new architectures, adding AI capabilities to existing applications, or wondering whether the grass really is greener on the edge, this book gives you the information to decide. > **Independent Work** > > This book is not produced by, affiliated with, or endorsed by Cloudflare, Inc. It represents the author's independent analysis and opinions based on publicly available documentation and years of hands-on experience with the platform. > **Feedback welcome** > > If you spot an error or disagree with an architectural argument, I'd like to hear from you at [jamie@architectingoncloudflare.com](mailto:jamie@architectingoncloudflare.com). Tell me what you tried and where the advice fell short. ## About the author I'm Jamie Lord, Solution Architect at CDS UK, working across government, policing and healthcare technology. Much of my work centres on Single Online Home, a platform connecting almost every UK police force with the citizens they serve. I lead technical decisions for a system handling millions of interactions daily, where reliability and response time affect people's access to public services. I've built offline-first mobile applications, turned legacy desktop software into multi-tenant SaaS platforms, and co-founded a privacy-preserving employee wellbeing startup as CTO. These projects left me with a practical interest in what happens after an architecture diagram meets production: synchronisation failures, growing tenants, awkward migrations and the cost of keeping it all running. At CDS, I work across Azure, AWS and Cloudflare on systems handling Official-Sensitive data, including digital evidence platforms and legacy modernisation. The assessments in this book reflect the questions I ask in that work: what must be true for this design to succeed, what could break it, and who will have to fix it? > **Commercial transparency** > > CDS is a Cloudflare partner and reseller, and became the first Cloudflare Authorised Service Delivery Partner in EMEA. We use Cloudflare's security and networking products in client work. My use of the Developer Platform also includes personal projects, chosen through technical evaluation. This relationship matters when weighing my recommendations; the book states where I would choose another platform. I wrote the book I wanted when evaluating Cloudflare: enough of the underlying model to make a decision, with the limits close enough to the benefits that you cannot miss them. ## My philosophy For a new application, my starting point is **try Cloudflare early and look for reasons it will not fit**. Global deployment, small runtime overhead and managed data services make a useful prototype inexpensive to build. That prototype should test the awkward part first: the largest tenant, the native dependency, the cross-region query chain, or the residency requirement. A successful hello-world deployment tells you little about any of these. This is my evaluation habit, not a reason to move a working system. Existing skills, database features and operational commitments can make a hyperscaler the better choice. Chapter 2 provides the assessment framework; Chapter 26 collects the reasons to choose something else. ## Who this book is for This book assumes you have context to compare against. The most value goes to readers who already understand cloud architecture and want to evaluate a different approach: - **CTOs and Technical Directors** who need to understand platform capabilities, strategic fit, and organisational implications - **Solution Architects** evaluating Cloudflare against hyperscalers for specific workloads - **Lead Developers and Engineering Managers** who must architect solutions and guide teams - **Senior Engineers** transitioning from AWS, Azure, or GCP who need to understand Cloudflare's different mental model The explanations assume familiarity with HTTP APIs, databases and cloud deployment. You do not need prior Cloudflare experience. ## How to use it Read Chapters 1 and 2 for the platform model and the adoption decision. Then follow the parts relevant to your workload. Each chapter opens with the question it answers and puts the main choices before implementation detail. If you are preparing a production design, read the operations chapters even when the prototype looks simple. If you are migrating, read Chapter 27 before choosing the destination: coexistence and rollback requirements can change that choice. Code examples isolate the mechanism under discussion. Unless identified as a complete file, they are excerpts: handler variables, application helpers, schemas and generated `Env` types come from the surrounding application. Configuration blocks show the relevant part of `wrangler.jsonc`; merge them into your project configuration and replace illustrative resource IDs. ## Book structure ### Part I: foundation Why Cloudflare thinks differently about compute, and how to decide if that difference matters for your workload. These chapters give you the mental models to evaluate everything that follows, plus a framework for knowing when to stop reading and use something else. ### Part II: compute & development The V8 isolate model and its implications for startup, memory and request lifetime. You'll understand why Workers feel different from Lambda, how to build complete applications without leaving the edge, how to develop locally, and how to use coding agents to turn architectural uncertainty into experiments with trustworthy results. ### Part III: stateful systems How to choose the unit of state and recovery. Durable Objects coordinate access to an entity; Workflows persist multi-step progress; Queues buffer independent work; Containers run workloads outside Workers' limits; Realtime handles audio and video transport. ### Part IV: data & storage Where data lives, who can change it, and what a stale read would cost. Choose among D1, R2 and KV, or use Hyperdrive to retain an external PostgreSQL or MySQL database. Carry operational facts into analytical reporting without losing their meaning or tenant boundaries. ### Part V: the AI stack How to evaluate model quality, retrieve useful context and constrain agents that can take actions. Compare Cloudflare-hosted and external inference, choose between managed and custom retrieval, separate a model's proposal from permission to execute it, and evaluate complete tasks before granting an agent more authority. ### Part VI: production What it costs, how to observe and secure it, and how to recover correct service after failure. Cost modelling, observability and security establish the operating boundaries; recovery connects durable acceptance, external effects and restored state. ### Part VII: architecture & decisions Patterns that work, patterns that don't, and the constraints you'll wish someone had told you earlier. Reference architectures for common problems, synchronisation that survives disconnection and changed permissions, multi-tenant designs that scale, and an honest catalogue of limitations that might send you back to hyperscalers. ### Part VIII: migration How to get here from there. Practical playbooks for moving Lambda functions, containerised services, and traditional backends onto Cloudflare, plus a synthesis of the principles that make edge-native architecture work. ## A note on platform state Cloudflare's Developer Platform evolves quickly. Features, APIs, limits and pricing change, so check the current documentation and pricing for the services your design depends on before committing to an architecture or budget. The questions should outlast the numbers: where does state live, which operations must agree, what happens after a partial failure, and how does cost grow with usage? Use the platform model to answer them, then check the limits that your design depends on. Build with the principles. Verify the specifics.