Blog
Why we killed realtime and bet on rate limiting
Brume started as realtime infrastructure. We removed the entire realtime stack and rebuilt around rate limiting. This is the honest accounting of why.
AnnouncementEngineering
Brume started as realtime infrastructure. We removed the entire realtime stack and rebuilt around rate limiting. This is the honest accounting of why.
Brume launched as realtime infrastructure: WebSocket channels, presence, transport fallback, message acknowledgements. Today we are removing all of it. Brume is now a rate-limiting gateway, and this post is the honest accounting of why.
Realtime infrastructure is a scale game. The incumbents — Ably, Pusher, Supabase, Firebase — compete on global edge presence, connection counts in the millions, and enterprise procurement. Winning that market means winning on scale, and scale is bought with money and years, not with good engineering.
We are one developer and a VPS in Frankfurt. We can build a correct, fast, honest gateway. We cannot out-scale Ably. Pretending otherwise would have spent the next two years losing slowly.
Rate limiting is the same engineering problem, pointed somewhere a small service can win:
And the competitive landscape is different. The leaders are a key-management company with rate limiting bolted on (Unkey), a library you run against Redis you pay for (Upstash), and an edge product that cannot see your users (Cloudflare). None of them is a hosted, flat-rate, per-identifier rate-limiting service. That gap is exactly our size.
Everything realtime. The WebSocket engine, presence, transport fallback, message acknowledgements, JWT auth, five SDK packages, the realtime dashboard views, the realtime docs. If it existed to move your messages, it is gone. We did not keep a half-alive realtime surface around for nostalgia; a product that is half-committed to two markets is committed to neither.
The parts that were always the actual product:
Four algorithms (token bucket, fixed window, sliding window log, sliding window counter), limit and check endpoints, multi-rule evaluation, per-identifier overrides, long-window quotas, block & allow lists, per-identifier analytics, and a small typed SDK with an ephemeral cache and explicit failure fallbacks. See the v0.2.0 changelog for the full list.
Cutting is a feature. Every realtime line we deleted was a line we no longer had to defend, document, or keep honest. The codebase got smaller, the story got sharper, and the product got closer to something one developer can operate at a level we are willing to put our name on.
If you came here for realtime, we are sorry, and we would rather tell you that plainly than waste your integration time. If you came here to stop writing rate-limiting code, the getting started guide takes about two minutes.