Architecture Shift
Why I use Cloudflare for new projects.
I came up through WordPress and the broader PHP ecosystem, running and maintaining hundreds of sites. The shift for me wasn't about framework wars. It was about operational overhead and system boundaries. This page is the practical version of why I changed stacks.
The Core Shift
Traditional stacks bundle concerns together. This approach separates them.
A traditional stack couples your web server, application logic, background jobs, session state, cron schedules, and database queries into one deployment unit. That coupling is why scaling is painful, deploys are risky, and operational overhead grows with every feature you ship.
Design around primitives instead, and each concern gets the right tool:
Compute
Requests, not servers
Workers run at the edge, 300+ locations, no provisioning. A request arrives, your code executes, the response goes out. No instances. No autoscaling configuration. The platform routes it.
State
One owner per piece of state
Durable Objects give you single-writer consistency with colocated coordination logic. If you can't point to what owns a given piece of state, you have a design gap. Durable Objects make that explicit.
Storage
Right tool per access pattern
Relational data in D1. Large objects in R2. Hot keys in KV. You stop shoving everything into MySQL because MySQL is what you have, and start picking by what the data actually needs.
Execution
Durable by default
Queues with retries and dead-letter handling. Workflows with checkpoints and deterministic replay. No more cron jobs that silently fail at 3am because one machine had a bad day.
Observability
Part of the runtime
Workers Observability and Analytics Engine give you request traces and operational telemetry without APM agents, custom log pipelines, or a separate Grafana stack to maintain.
Security
At the edge, not in middleware
WAF, Access, Turnstile, Zaraz -- the security layer lives before your code runs. Less security logic in app code means a smaller surface and one less thing to audit in every deploy.
Why Not AWS / GCP
Why Cloudflare specifically (for me).
AWS and GCP can absolutely support the same architectural patterns. I've built on those ecosystems too. For my workflow, Cloudflare's advantage is how tightly the primitives fit together in one runtime boundary.
Workers, Durable Objects, D1, R2, KV, Queues, Workflows, Vectorize, Workers AI -- they're
all bound to the same Worker via a single wrangler.toml.
No separate credentials. No separate service topology. One
wrangler deploy
and all of it is live in 300+ locations simultaneously.
The edge-first model means compute follows the request by default. For global traffic, that removes a lot of region planning work and keeps latency more predictable.
How I Design
A few things I keep coming back to.
Start with capabilities, not services
What does this system need to do? Render pages, process payments, run background automation, coordinate execution. Each capability maps to primitives -- not to servers, not to microservices for their own sake.
Make state ownership explicit
Every piece of state has one clear owner and a defined consistency model. If you can't answer "who owns this state?", the design is incomplete. Fix the design, not the symptom.
Execution that's durable by default
If a process matters, it should survive failures. Event-driven fanout, retry policies, dead-letter queues, workflow checkpoints. The goal is fewer silent failures and clearer recovery paths.
Security at the perimeter
Auth, rate limiting, bot detection, and governance belong at the edge, not scattered through application middleware. The less security logic lives in app code, the smaller the attack surface.
Name your exceptions
Not everything fits this model. Some workloads need containers. Some data has residency requirements. Design for those explicitly. Don't pretend the happy path covers everything.
Deep Dives
Primitives
Each Cloudflare primitive -- what it does, what it replaces, and how the architecture shift changes your system design.
Comparison
Why Not Laravel
A practical comparison of operating models. It covers Laravel Cloud, Octane, and FrankenPHP, and where Cloudflare's primitives differ.