🏎️ Zero To Sixty... Thousand Eight Hundred And Ninety 💨

60,890. That's the number of concurrent users less than two minutes after a tweet from a very popular band. I had agonized in anticipation for that tweet. I was as ready as a one person team could possibly be - but still the burst of numbers was intense.

60 thousand concurrent users (will it scale... yes), 70 thousand (will it scale... yes), 80 thousand (will it scale... yes), 30 minutes later it peaked. 110,427 concurrent users, well over the 80K estimate I had. But it scaled. No hiccups. May as well have been 10 concurrent users. What a fun way to make a living.

How I got into this situation

I've been sustaining myself for the last decade by building products from start to finish entirely solo. You could call me a solopreneur, but I feel like that term is linked to business influencers selling "ship fast" and "win big" advice on twitter so I don't use the title if I can help it.

I build products by myself because I enjoy doing it. The product velocity is crazy and I get to work on lots of different things and utilize lots of different skills. I also, for the large part, get to avoid office politics and have the final say when it comes to decision making in any aspect.

At the start of my solo journey in 2016 I founded a social music service called JQBX and ran it as a free service for close to 7 years *having no business model is a big mistake if you're going solo... just FYI. The service coasted along as a side project for several years and I ran it in the background as I was working on eCommerce and survey software (contact me for a demo 😉).

In 2020, when COVID hit there was a huge spike in JQBX users. It happened fast - peaking at about 100K MAUs which was roughly 5X the previous high. And with that peak came emails from the big labels asking if they could use the product for marketing artists and new albums.

I was in a haze, the world was upside-down and I had to deal with the surge in traffic so my initial answer was non-commital, something like:

Once the COVID fog cleared a little bit, it was clear that the demand was there. The new "shelter in place" moment created a hole in the market for live events and I rushed to fill it with a working product. I got to work on a tangential "listening party" platform where you could chat with other people in real time while listening to content (albums, playlists, videos etc...) in sync with everyone else who joined. The goal was to meet this new use-case head on and allow artists to run digital concerts and album release events digitally while the world was still on pause.

Every event was very white label, but this is roughly how the product looked.

Working in the music industry

Let's get this out of the way: I would not recommend building software for the music industry. Why? Here's a few reasons:

• Their budget for digital is small.
• Their audience is massive.
• Their requirements are quick to change

In short: their budget is low and their requirements are high. It's just the nature of the industry - it is a low margin business with a lot of managers involved. This is a hard environment to thrive in and to make matters worse, due to the "cool factor" the software ecosystem is competitive despite these constraints.

Initial traction

Roughly six months after the first line of code the new listening party product got some traction with a few major labels and the first event was booked. It clocked around 300 concurrent users and lasted for a couple of hours, I got to chat with an artist who went platinum a couple of days before the event. It was great. I was hyped. I ran a few listening parties successfully for 5 or so other acts over the next three months. Then the email from the big guys came in.

How many users can this handle?

The discovery email was typical, something like:

At this point I was in the habit of saying yes to anything (every project had been a breeze up until that point). So I took the call and I said:

Now, in theory, it should have been able to handle as many users as you throw at it - but every developer knows that theory is different from practice.

A couple of weeks later, after I had commited, I learned who the event was for and what kind of numbers to expect. My first reaction was to double check everything. I ran audit after audit, test case after test case, load test after load test.

Accepting the task, setting the stage

Weeks of preparation, agonizing over every choice, contacting support, discussing sharding options, session settings, watching the artist on the grammys, reviewing caching options, horizontal scaling options, vertical scaling options - it never ended. I ran load tests, I bought servers to simulate traffic but it never felt secure because you never know until you know.

It's one thing to do this as a team, but it's another when you're the sole point of contact and the sole technical expert so everything fell on me. Any 11th hour bug would fall squarely on my shoulders to resolve and communicate and it would all have to be done in real time, this was the big leagues.

When the lights shine...

The morning that it went live was rediculous. Very much a hurry up and wait kind of morning. For the first several hours I just sat there at the computer with a pit in my stomach. I was poring over checklists and waiting to hear from management that the announcements from the band went up on social media.

Then it happened. 60 thousand concurrent users (will it scale... yes), 70 thousand (will it scale... yes), 80 thousand (will it scale... yes), 30 minutes later it peaked. 110,427 concurrent users. But it scaled. No hiccups. The theory worked. The hours of research and code review paid off. I don't worry much about how to build projects that scale anymore.

Questions or Feedback?

We are always ready to hear from you.