Keeping a Real-Time App at $0/Month: Account Sharding and Durable Objects

Alphazord — Fri, 28 Aug 2026 04:55:00 +0000

Real-time delivery is usually where "free tier" architecture stops working. The moment you need sub-second delivery across many concurrent conversations, most people reach for a dedicated WebSocket server — and a bill that comes with it.

Here's a different approach, used to build and run a real-time group chat app in 5 days on $0/month infrastructure at its current scale.

The core problem

Real-time chat needs two things that don't naturally coexist on a shared, single-tenant server: isolation (one busy conversation shouldn't slow down every other conversation) and low, predictable latency at the edge, close to wherever the user actually is.

The approach: isolate, then shard

Each conversation runs in its own Cloudflare Durable Object — an isolated compute environment scoped to exactly one conversation. That solves the "noisy neighbor" problem structurally: there's no shared event loop for one busy group chat to monopolize.

The second piece is splitting the whole system across multiple Cloudflare accounts — 8 accounts, 7 shard workers in the current setup — rather than trying to run everything inside a single account's free-tier limits. Each shard worker owns a slice of the traffic, so no single account's limits become the ceiling for the whole app.

Combined, the target is sub-100ms message delivery — a target the architecture is designed around, not a number that's guaranteed under every possible load.

What this pattern is useful for beyond chat apps

Anything with many small, independent units of real-time state — presence systems, collaborative editing, live auctions, multiplayer game rooms — can use the same isolate-then-shard shape: Durable Objects (or an equivalent per-unit isolation primitive) for correctness and blast-radius containment, account/worker sharding for staying inside free-tier or cost-sensitive limits as you scale.

Where it gets harder

Sharding across accounts is not free complexity-wise — routing a given conversation to the correct shard, and handling shard rebalancing if one account's limits get closer to being hit, both need real design attention. This isn't a "just add Durable Objects" one-liner; it's a genuine architectural decision with trade-offs.

In production

This exact pattern is running today as BatchUp (batchup.fun), a real-time chat app currently live for a college community, built solo in 5 days.

DEV Community: Alphazord

Keeping a Real-Time App at $0/Month: Account Sharding and Durable Objects