Cloudflare Workers architecture patterns I keep reusing

Cloudflare Workers are not just functions at the edge. Used well, they change how you draw boundaries between API, data, background work, and product operations.

Across Flare Control, Gorgi, JigSpot, and Questline, I keep returning to a few patterns.

One Hono app, clear route boundaries

For early products, a single Worker with a Hono app is often enough. The key is not splitting too early. Keep route boundaries clear, keep services small, and separate public routes from authenticated dashboard routes.

This reduces deployment surface while the product is still changing.

D1 for truth, R2 for artifacts

D1 is a good fit for relational product state: users, projects, runs, settings, usage, and audit records. R2 is better for files, generated artifacts, map bundles, and anything you do not want inside a relational database.

The common mistake is using one storage primitive for everything.

Queues for work, not loops

If the system has background work, model it as messages. Queue consumers are a clean fit for ingestion, agent runs, email jobs, sync work, and anything that can be retried.

This is especially useful for AI systems where runs may be expensive, bursty, or slow.

Durable Objects only when coordination is the point

Durable Objects are powerful, but they should not become the default database. Use them when you need strong coordination around a specific key: locks, live sessions, rooms, or single-writer state.

Everything else should earn its way in.

Product operations are architecture

Cost limits, rate limits, audit trails, and admin visibility are not extras. They are part of the system design, especially when AI calls or user-generated work is involved.

If you are deciding whether Cloudflare is the right backend shape for a product, start a conversation.