The Real-Time Scaling Tax: How AnyCable Solved the WebSocket Problem That Kills Monolithic Performance

If you’ve ever built a collaborative tool—think Figma’s live cursors or Google Docs’ simultaneous editing—you’ve bumped up against the same problem: WebSockets don’t play nicely with traditional server architecture.

That’s the insight that sparked AnyCable, an open-source WebSocket server that’s now powering production systems for companies like DocSimpilty, which serves roughly 80% of doctors in the United States. But the story of how it got there is a masterclass in identifying a real technical problem, building for a specific community, and evolving a product based on what production systems actually need.

The Problem Nobody Wanted to Admit

When most developers think about scaling web applications, they think about HTTP requests. Those are stateless, predictable, and relatively easy to throw infrastructure at. But WebSockets are different. They’re persistent connections—always open, always listening. That’s what makes them perfect for real-time features. It’s also what makes them a nightmare for monolithic architectures.

“There’s a big difference between what you think this technology should have and really seeing a bunch of production use cases where people use it in all sorts of ways,” Irina explains. “Even if you think about what’s on the server, what’s on the client, there can be a gap in between. There’s a bunch of different scenarios that you probably aren’t thinking about when you’re just starting.”

The core issue? WebSocket connections consume server resources differently than HTTP requests. They’re stateful. They need to stay open. They create memory overhead. And when you try to scale them across multiple servers, you hit a wall: message delivery isn’t guaranteed. Connection issues happen. Messages get lost. And most existing solutions just… don’t care.

Building the MVP: Open Source, Drop-In Replacement

When Evil Martians decided to build AnyCable, they made a strategic decision that shaped everything that came after: start with open source.

“If you’re building a tool for developers, just go in with open source. That’s what I would always default to,” Irina says. “Just build something in open source and for us, we particularly built a drop-in replacement for an existing part of Rails.”

Rails had introduced WebSocket support through Action Cable, but it had limitations. AnyCable’s MVP was elegantly simple: rewrite the same functionality in Go (for performance and memory efficiency) and make it a drop-in replacement. Users wouldn’t need to change their code—just update a configuration file.

This wasn’t just a technical choice. It was a go-to-market strategy. By targeting the Rails community specifically, AnyCable had built-in advantages: existing relationships, trusted networks, and an audience already grappling with the exact problem they were solving.

“We built for a community we knew really well,” Irina explains. “The Ruby on Rails community. We had lots of friends, lots of people, lots of companies, lots of clients. They gave us a lot of feedback right away. They noticed us right away.”

Listening to Production, Not Just Feedback

Here’s where many developer tools fail: they optimize for what users say they want, not what they actually need. AnyCable took a different approach.

The team established a playbook: get customers, publish case studies with them, learn from their real-world usage, and iterate. But they weren’t treating all feedback equally. They prioritized companies with real traffic, real users, and real problems over hobby projects.

One of the clearest examples came from the GraphQL wave. When GraphQL emerged around the same time, developers wanted to use it for real-time subscriptions. “A lot of people envision that GraphQL will give them this instant declarative reactivity right away,” Irina notes. “But they need a performance WebSocket server for this.”

So AnyCable built GraphQL support. Not because it was on some abstract roadmap, but because real companies needed it to solve real problems.

The Evolution: From Drop-In to Differentiated

Here’s the interesting part: AnyCable started as a drop-in replacement, but it couldn’t stay that way forever.

“Years later, we actually have our own protocol because we had to extend the protocol to achieve more,” Irina explains. As they worked with production systems, they discovered gaps in the original Action Cable protocol. They needed better message ordering. They needed guaranteed delivery with automatic recovery during connection issues. They needed presence tracking that actually worked at scale.

So they built it. And in doing so, AnyCable stopped being a replacement and became something genuinely differentiated.

The Business Model: Open Source + Pro Tier

This is where AnyCable’s strategy gets interesting. The core product is open source (MIT licensed), but they’ve built a commercial path that makes sense for their users.

AnyCable Pro is tuned for cluster mode—when you’re running multiple AnyCable servers and need sophisticated coordination between them. That’s where customers pay for licenses. There’s also a free SaaS version for trying things out.

“We commercialize the side of the business where we think those use cases can pay us,” Irina says. “We sell licenses, which is a bit unique because most people sell SaaS.”

It’s a model that respects the open-source community while creating a sustainable business. You can run AnyCable for free if you’re willing to manage the infrastructure yourself. But if you want a managed, clustered solution, there’s a commercial option.

Finding the Next Market: Niche Wins Over Obvious Moves

The roadmap today reflects something that surprised Irina and the team: niche use cases often outperform obvious ones.

“We published a blog post about integrating Twilio and AnyCable for voice AI agents,” she recalls. “You could think, ‘Oh, it’s so niche, right?’ How many people want to integrate Twilio and AnyCable? But for some reason we do have a lot of traction from these very niche things.”

Meanwhile, a demo published on Vercel’s website—a much more visible platform—generated less interest.

The lesson? When you’re looking for your next market, sometimes the most obvious moves aren’t the best ones. Sometimes you need to follow the signals from production systems, from real companies solving real problems, even if those problems seem niche.

The Takeaway

AnyCable’s journey from open-source project to production infrastructure powering major healthcare platforms reflects a fundamental truth about building developer tools: listen to production, build for a specific community, and let the product evolve based on what real systems actually need.

The “scaling tax” of WebSockets—that hidden cost in memory, connection management, and message delivery—is real. But it’s not unsolvable. It just requires rethinking how you architecture your real-time layer.

Want to hear the full story? Listen to the complete conversation with Irina Nazarova on Code Story to dive deeper into Evil Martians’ journey, the technical decisions that shaped AnyCable, and what it takes to build infrastructure products that developers actually adopt. Listen now →