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

如何将实时应用维持在 $0/月：账户分片与 Durable Objects

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.

实时交付通常是“免费层级”架构失效的地方。一旦你需要跨多个并发会话实现亚秒级交付，大多数人会选择专用的 WebSocket 服务器——随之而来的还有账单。这里有一种不同的方法，它被用于在 5 天内构建并运行一个实时群聊应用，且在当前规模下基础设施成本为 $0/月。

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.

每个会话都在其专属的 Cloudflare Durable Object 中运行——这是一个仅针对单个会话的隔离计算环境。这从结构上解决了“吵闹邻居”问题：没有共享的事件循环供某个繁忙的群聊独占。

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.

第二部分是将整个系统拆分到多个 Cloudflare 账户中（当前配置为 8 个账户、7 个分片 Worker），而不是试图将所有内容都运行在单个账户的免费层级限制内。每个分片 Worker 负责一部分流量，因此任何单个账户的限制都不会成为整个应用的上限。综合来看，目标是实现 100 毫秒以内的消息交付——这是该架构设计的核心目标，而非在任何负载下都能保证的绝对数值。

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.

任何具有许多小型、独立实时状态单元的应用——如在线状态系统、协作编辑、实时拍卖、多人游戏房间——都可以使用相同的“先隔离后分片”模式：利用 Durable Objects（或等效的单元级隔离原语）来确保正确性和控制故障影响范围，利用账户/Worker 分片来在扩展时保持在免费层级或成本敏感的限制内。

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.

跨账户分片在复杂性上并非没有代价——将特定会话路由到正确的分片，以及在某个账户接近限制时处理分片重平衡，都需要真正的设计考量。这不是一句“只需添加 Durable Objects”就能解决的，这是一个需要权衡的严肃架构决策。

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.

这种模式目前正应用于 BatchUp (batchup.fun)，这是一个目前为某大学社区提供服务的实时聊天应用，由个人在 5 天内构建完成。