I mapped a Cloudflare SaaS architecture before writing any code.
In a November 2025 video I mapped a SaaS architecture on Cloudflare from zero, aimed at vibe coders who have never built an app at scale and want to reach $30K a month in recurring revenue. I didn't write production code in that session. I drew the diagram, one piece at a time, so you can tell which Cloudflare service holds what before you build.
The business case
If you're building a community or hunting for leads, you probably bounce between Reddit, LinkedIn, Facebook groups and Hacker News to see which conversations are worth joining. I was doing that myself. A LinkedIn post I wrote about Cloudflare's outage that week got about 2,600 impressions, where my posts usually see around 100, and the replies included people who might work with me later.
The example app in the video is called Cloud Signal. It monitors the communities you pick, pulls the conversations back, summarizes them with AI, and puts them on one dashboard. Think Google Alerts for community threads. I sketched it in Miro, on the free plan, because I was still deciding whether I needed more than that.
The first version of the diagram
The simple version has five parts:
- An app with a dashboard and a button to run a scan.
- A Cloudflare Worker that reads results, and a second Worker that does the monitoring.
- Cloudflare's browser, which the monitoring Worker uses to fetch pages and take screenshots.
- An LLM call to summarize what the browser brought back. OpenAI, Anthropic or anyone else works here.
- D1 for the summaries and R2 for the screenshot images.
I wished on camera that Cloudflare had a NoSQL database, because scraped data is messy and the shape keeps changing. D1 pushes you toward a structured table, although you can store a JSON blob in a single column.
That design works, but every step runs in line. It doesn't answer four questions that come up once real users show up: how the app tracks state across many pages, how you show live progress, what happens when the LLM provider goes down the way Cloudflare did that week, and where each site's config lives.
Which piece stores what
Picking the right storage is where most beginners get stuck, so I gave each piece a plain rule.
Database (D1). Use it for anything you keep long term: more than 90 days, years, forever. In Canada you have to keep tax paperwork for years. That belongs in a database.
Cache (KV). Use it for short-lived data. API tokens should rotate, so you need them for an hour or a few hours, and storing them in a database means writing cleanup code later. Dropdown lists are my other common case. The Worker reads them from the database once, writes them to KV, and serves the next request from KV.
I added a caveat in the video: on D1 there's little benefit to caching like this. The pattern pays off when you connect to Postgres or Supabase, which is Postgres under the hood.
Jump to
- 0:00 Introduction to Scalable Architecture
- 0:47 Understanding the Problem
- 2:19 Building the Application: Cloud Signal
- 9:59 Detailed Architecture Breakdown
- 20:28 Exploring Storage Solutions
- 26:20 Understanding Database Connections
- 26:46 The Bus Analogy for Database Connections
- 27:48 Connection Pools and Bottlenecks
- 29:25 Introduction to CloudFlare D1 Database
- 30:49 Differences Between D1 and Postgres Databases
- 32:07 The Role of Caching in Databases
- 32:37 Using Queues for Deferred Processing
- 33:31 Exploring Durable Objects
- 38:48 Real-Time Data with Durable Objects
- 42:09 Vector Storage and AI Integration
- 45:23 Building a Scalable Architecture
- 52:11 Implementing an AI Gateway
- 56:13 Conclusion and Next Steps
I drew the full diagram, one piece at a time, in the video on my channel: Cloudflare SaaS architecture from zero on YouTube.
The bus analogy
The difference comes down to connections. A Postgres database works like a school bus with one door. Every request opens the door, gets on, sits down and closes it. That door is the connection pool. With enough riders you get a line outside, and that's the point where people ask why the app is slow.
D1 is file-based, closer to opening a Word or Excel file than dialing in over the network. In my analogy the whole side of the bus is open, and Cloudflare handles the hard parts in the background. It's a simplification, but it explains why the caching math changes on D1.
Queues, Durable Objects and vectors
Queues are for work that has to happen later and has to finish. Payments are the clean example. You take the card, put the job on a queue, and let the customer leave while Stripe and the banks process it. In the improved Cloud Signal diagram, the scan button drops a small JSON command on the queue, something like "scrape this site, save a screenshot." A consumer Worker picks it up. If the site fails, the job goes back on the queue. After about five retries it moves to a dead letter queue for someone to check.
Durable Objects confused me too when I read Cloudflare's definition out loud. My plain version: they push updates to the browser over a WebSocket instead of having the page ask again every 10 seconds. A live counter, a leaderboard or everyone's cursor on a shared page all work this way. If 10,000 browsers poll your database every 10 seconds, it times out.
Vector storage keeps text as numbers, so a search for "hello" can find "greeting" even when the word itself isn't stored. Keyword search finds nothing in that case.
The improved diagram
The final version keeps the button, but the monitoring service now produces jobs onto a queue and a consumer handles the browser work. Reads check KV first and fall back to the database. A Durable Object pushes dashboard changes, and the summarize step goes through Cloudflare AI Gateway. With the gateway, switching from OpenAI to Anthropic or Workers AI means changing the provider key and the model in one line, and the response format stays the same.
Start with the diagram
I ended that session with the map and left building Cloud Signal for a follow-up. Cloudflare's product names and limits move, so check the docs for D1, R2, KV, Queues, Durable Objects, Vectorize and AI Gateway before you copy any of it. If you want a second set of eyes on your own architecture, that's what I cover in a 1:1 strategy call. For more on keeping a first build small, see the smallest system that proves the point, and come build with others in Vibe Code to Profit.
About Dwain
I'm Dwain Browne, Founder of LeadScore AI and SnapSuite. I'm a Toronto-based software architect with 25+ years across software, sales, operations and entrepreneurship. SnapSuite helps contractors and trades teams get paid faster, and LeadScore AI shows you which leads deserve your next call. I also run Vibe Code to Profit, a community helping people build software with AI.