Cloudflare Workers Architecture Diagram: Edge Computing & AI Inference (2026)

Cloudflare Workers architecture diagrams visualize applications built on Cloudflare's edge computing platform — a distributed runtime that executes JavaScript, TypeScript, and WebAssembly across 300+ data centers worldwide, typically within 50ms of any user. Unlike traditional serverless functions that run in a single region, Workers run at the network edge, fundamentally changing how latency, data locality, and global state must be designed. Cloudflare's ecosystem has grown into a full application platform — Workers, Durable Objects, KV, R2, D1, Queues, Vectorize, and AI Gateway — and architecture diagrams help teams understand how these primitives fit together into coherent systems.

Core components of a Cloudflare Workers architecture diagram

• Workers: Lightweight JavaScript/TypeScript functions that run at the edge, handling HTTP requests, scheduled Cron Triggers, and Queue consumers. Each Worker runs in an isolate (not a container or VM), with sub-millisecond cold starts. Show Workers as the primary compute nodes, annotated with their trigger type (HTTP, Cron, Queue)
• Durable Objects: The stateful primitive — each Durable Object is a single-threaded JavaScript class with in-memory state and a small persistent SQLite database, uniquely identified by a name or ID. Durable Objects are the solution for coordination problems: websocket hibernation, rate limiting, real-time collaboration, and distributed locks. Show Durable Objects as globally unique actors that Workers communicate with
• Workers KV: A globally distributed eventually-consistent key-value store optimized for high-read, low-write workloads. Values up to 25MB; eventual consistency means writes propagate to all edge locations within ~60 seconds. Ideal for caching, feature flags, configuration, and session data that doesn't need strong consistency
• R2 (Object Storage): S3-compatible object storage with no egress fees. Workers can read and write R2 objects directly from the edge. Use R2 for user-uploaded files, static assets, model artifacts, and large data sets. Show R2 buckets connected to Workers that read/write objects, and annotate public access settings
• D1 (SQLite at the edge): Cloudflare's serverless SQL database based on SQLite, running close to users via read replicas. D1 is appropriate for relational data in edge-native apps. Show D1 databases connected to Workers that execute SQL queries, noting that D1 uses eventually-consistent replication from a primary write region
• Queues: Cloudflare Queues provide at-least-once message delivery between Workers — a producer Worker enqueues a message, and a consumer Worker processes it asynchronously. Useful for background jobs, webhook fanout, and rate-limiting API calls. Show Queues as intermediary nodes between producer and consumer Workers
• Vectorize: A vector database built for Workers, storing and querying high-dimensional embeddings for semantic search and RAG applications. Workers can insert vectors and query by cosine similarity directly at the edge. Show Vectorize as the retrieval layer in edge-native RAG architectures
• AI Gateway: A caching and observability proxy for AI API calls (OpenAI, Anthropic, HuggingFace, etc.). Workers route LLM requests through the AI Gateway, which logs requests/responses, caches repeated identical prompts, enforces rate limits, and provides a unified observability layer. Show AI Gateway between Workers and external LLM providers
• Workers AI: Inference directly on Cloudflare's GPU infrastructure, accessible from Workers without egress. Supports open-weight models (Llama, Mistral, Whisper, BAAI/bge embeddings). Show Workers AI as an on-platform inference option distinct from external LLM provider calls

Common Cloudflare Workers architecture patterns

Edge-first full-stack app (Remix / Next.js on Workers)

Remix or Next.js deployed to Cloudflare Workers via the @cloudflare/next-on-pages adapter or wrangler. The Workers runtime serves SSR pages from the edge (globally distributed), with no origin server. D1 handles relational data (users, content), R2 handles file storage, KV caches rendered pages or session tokens. Durable Objects manage WebSocket connections for real-time features. The diagram shows: user → Cloudflare edge → Worker (SSR) → D1 + R2 + KV — all within the Cloudflare network.

Edge RAG with Vectorize and Workers AI

A RAG pipeline built entirely on Cloudflare's platform. Document ingestion: a Worker processes uploaded files from R2, generates embeddings using Workers AI (BAAI/bge-base model), and upserts into Vectorize. At query time: a Worker receives the user's question, generates a query embedding via Workers AI, queries Vectorize for the top-5 similar chunks, retrieves the full chunks from D1 or KV, builds a prompt, and calls an LLM via AI Gateway (routing to OpenAI or Anthropic based on model availability). Responses are streamed back to the user. The entire pipeline runs at the edge with no centralized backend.

API gateway with rate limiting via Durable Objects

A Worker acts as an API gateway, proxying requests to origin services. Rate limiting is implemented using Durable Objects: each user or API key maps to a Durable Object that tracks request counts within a sliding window. The gateway Worker calls the appropriate Durable Object with each request; the Durable Object increments the counter and either allows or rejects the request — all in a single round trip at the edge, with no Redis or external state store. The diagram shows: client → gateway Worker → rate-limit Durable Object (allow/deny) → origin service.

Webhook fanout pipeline

An inbound Worker receives webhook events (from Stripe, GitHub, Twilio), validates signatures, and enqueues them to a Cloudflare Queue. Multiple consumer Workers process different event types: payment events update D1, GitHub push events trigger CI-style pipelines, Twilio SMS events update contact records. A dead-letter Queue captures failed events for retry. The diagram shows the inbound Worker as a fan-out point, with the Queue as the buffer and multiple consumer Workers as subscribers.

Prompt examples for Cloudflare Workers diagrams

Edge AI API with caching

Real-time collaboration with Durable Objects

Cloudflare Workers vs other edge/serverless platforms

What to annotate on a Cloudflare Workers diagram

• Storage consistency model: Label KV (eventually consistent), D1 (strong consistency on primary, eventual on replicas), and Durable Objects (strongly consistent via single-threaded execution) — this is critical for understanding correctness guarantees
• Durable Object location: Durable Objects have a home location (the Cloudflare region where their storage lives). Annotate whether the DO is location-pinned or uses automatic location selection — this affects latency for global users
• AI Gateway routing: Show which LLM providers are in the AI Gateway fallback chain and what the cache TTL is — this is key for cost and reliability planning
• CPU time limits: Workers have CPU time limits (10ms on the free plan, 30s on paid plans). Annotate compute-intensive operations (embedding generation, image processing) to flag where CPU limits may be hit
• Binding types: Workers access other services via bindings declared in wrangler.toml. Annotate the binding name and type (KV_NAMESPACE, DURABLE_OBJECT_NAMESPACE, R2_BUCKET, D1_DATABASE, QUEUE, AI) so engineers can cross-reference the config

Related guides: edge AI architecture, serverless architecture diagrams, RAG architecture diagrams, and serverless architecture use cases.