Why we built Thunderclap

We spent the last month building Thunderclap, a realtime service we needed for our other company, Line 21.

Line 21 delivers live captions, written by human captioners or by AI. (If you run events, work at an audio or video company, or caption for a living, take a look at line-21.com.) Thunderclap began as the piece of infrastructure Line 21 was missing. This post explains why.

Captions for a crowd you can't predict

A big part of Line 21's job is getting captions to viewers. When they aren't burned into a video stream, they're shown on a web page, and that page needs a steady stream of realtime data from our servers.

Sending it is the easy part. WebSockets or Server-Sent Events will do. Scaling is the hard part. On most days we serve a few hundred viewers, but a single event can bring tens of thousands, and we have to be ready for hundreds of thousands. They all arrive at once, when the event starts. So we don't just need to scale. We need to scale fast.

You could run your own fleet of servers for that. But our traffic has a particular shape: one producer and a great many receivers. That's exactly the model Pusher made popular. Our backend publishes each caption once, and the service takes care of getting it to everyone. We don't run the connection infrastructure, and we can grow as far as the service can.

All good. Or is it?

Pusher: the right model, the wrong bill

We've used Pusher for this kind of product for years, and Line 21 is only the latest. Every time, we ended up looking for an alternative. The technology was never the problem. The pricing model was.

Plans have hard limits, and spikes don't wait for you. Most of the time we serve a few hundred viewers. Then, often without warning, thousands or tens of thousands show up. Connections multiply, messages multiply, and suddenly our plan isn't enough. Pusher emails a warning as you approach the limit and leaves some headroom past it,³ but moving to the next tier is a manual decision, and spikes rarely come at a convenient time: it might be the middle of the night where our team lives, or the whole thing might be over before anyone notices. Nothing adjusts the plan automatically. So someone has to keep an eye on capacity all the time. If nobody acts in time, new connections are refused and publishing fails.²

Every delivery counts as a message. On Pusher, publishing one message to 100 subscribers counts as 101 messages, and the allowance resets every day.^1,4 For a broadcast like ours, it runs out long before the connection limit does: on the $99 Pro plan (2,000 connections, 4 million messages a day)¹, a caption every two seconds to 2,000 viewers uses up the whole day's messages in about an hour.

The only real fix is to pay for a plan sized for your busiest day, and to be heavily over-provisioned on every other day of the month.

Soketi: the promise that stalled

We weren't the only ones looking. Over the last few years several open-source alternatives have appeared, and the best known is Soketi. It speaks Pusher's protocol, and it later offered a managed service, Soketi Cloud.

Being able to host it ourselves wasn't the attraction. At our size we'd much rather pay for a service than maintain servers for something that isn't our core business. Still, we tried Soketi, and we were happy with it until two things happened.

First, the project stalled. The code is still there, but the last release, 1.6.1, came out in March 2024,⁶ and Soketi Cloud's sign-up has been unreachable since at least November 2025.⁷ We'd be glad to be proved wrong, so if you know otherwise, please tell us.

Second, our Soketi setup failed at the worst possible moment: during a client's big event. Many viewers stopped receiving captions, and some couldn't connect at all. It was a scaling problem, and Soketi isn't designed to scale easily or without limit.

Given how uncertain Soketi's future looked, we went back to Pusher and paid more than we wanted to.

What we needed

By then our requirements were clear. We needed a service that:

• scales without a ceiling we have to manage, with users connecting close to wherever they are (Pusher runs each app in a single region⁵);
• charges a fair price for everyday use, and pay-as-you-go rates for spikes instead of a jump to a bigger plan;
• speaks Pusher's protocol, so that moving over means changing a host and a set of credentials, not rewriting code.

We built Thunderclap as if Line 21 were its first paying customer. That clarity is the reason the result works as well as it does.

What we built

Thunderclap is the service we wanted to buy. Here's what we're proudest of.

You pay for the messages you publish, not the ones we deliver. Send one message to a million subscribers and it counts as one message. Your allowance is monthly,⁸ so one busy day doesn't decide your plan.

Spikes aren't capped, and short ones are free. On a paid plan, nothing gets cut off when traffic jumps. You pay overage only for usage beyond your plan, and connections are billed at the 95th percentile of the month's hourly peaks.⁸ In practice, your busiest 5% of hours (about 36 in a month) don't count toward the bill. An event that lasts an evening doesn't change it.

It grows on its own. Users connect to the edge location nearest them, and capacity comes online as people arrive.⁹ We've measured how far that goes, and you can read the numbers in How far does Thunderclap scale?.

Migrating starts with a host change. Your existing Pusher libraries work as they are.¹⁰ Point them at Thunderclap and move to our own SDKs at your own pace (the migration guide shows how).

Come and build with us

Thunderclap is open, with a waitlist we're letting people in from quickly. Join it. We can't wait to see what you build.

We're shipping fast, too. If you have feedback or a question, or just want to say hello, write to us at hello@thunderclap.dev.

— The Thunderclap Team

Sources