The Scalability Nightmare of the SXSW Superstar Apps

Stacktical Team
4 min readMar 10, 2016

--

South by Southwest Interactive is considered by many to be one of the most impacting technology event of the world.

It’s a formidable launch platform for startups, with a quite unique history of having significantly accelerated the growth of major consumer products like Twitter or Foursquare. 2016 might be the year of Anchor, a polished audio blogging app experience, Tribe, the cool video messaging app from France.

But from an infrastructure scalability standpoint, what does it mean to be the superstar of a festival gathering dozens of thousands attendees each year (33,850 from 85 foreign countries in 2015)?

It means infrastructure hell.

Cloud Firefighters 🔥 and the Rise of Concurrency Heroes

SXSW is, by nature, a recipe for concurrency: the higher the popularity of your product, the higher the chances of having a sizable chunk of its many attendees using your application at the same time.

That makes launching at SXSW a daunting Capacity Planning challenge for infrastructure managers and their teams.

Behind the scenes, and far from flattering tech blogs articles and fancy parties, they have the huge responsibility of handling aggressive pre, during and post SXSW user loads.

Something that requires a long, rigorous preparation.

📈 Tackling Capacity Planning using Load Testing

Nailing down your Capacity Planning strategy involves repeated cycles of defining, collecting and interpreting load testing campaigns until you get actionable results.

For example, if your team expects 3% of SXSW attendees to generate load on your application, you would ideally test, collect, interpret, rinse and repeat this cycle until you have enough data to ensure a concurrency of 900 (and believe us, that’s a very high number for a new product).

A common Capacity Planning technique could be to measure transaction rate per seconds against concurrency (simultaneous connected users in that case) and translate it into a chart that will highlight how performance penalties apply to their servers as load increases.

In some other cases, concurrency can refer to the number of CPU or threads. It all comes down to the nature of your product and, of course, to the kind of intelligence you’re looking for.

A load test output from the Siege tool: 145.54 transactions per second for a 99.37 user concurrency.

Business Scalability versus Infrastructure Scalability 💥

Whether you’re leveraging open source softwares like Siege or industry-leading technologies like HP LoadRunner, Capacity Planning has an important operational cost that quite defies the purpose of scalability: the ability for your company to fit the increasing and decreasing computing needs of your digital services so accurately that you never overspend your hosting budget or under-provision your servers.

A word of caution, through: many people misunderstand what Scalability is about. While it can definitely refer to the ability for a business to sustainably increase its revenue over time, Scalability is first and foremost a technological concept and the key metric of Capacity Planning.

Predicting Scalability with Stacktical ⚡️

Meet Stacktical, the first Scalability Prediction platform

SXSW is just an example of a particularly great challenge to handle. In reality, anybody can observe the Capacity Planning challenges that companies of all size have a hard time facing everyday.

We experience it as consumers when our favourite website goes down. And we experience it as technology professionals, sometimes during sleepless night of dealing with dreadful incidents.

A couple months ago, we’ve started an obsessive quest for a much faster, engaging and cost-effective way to plan for capacity.

And guess what? We believe we found it. We found that more than a technological concept, Scalability is actually a metric that can be mathematically quantified and predicted.

That’s exactly what our service, Stacktical, does.

Stacktical predicts the Scalability of your application infrastructure within seconds, using just a dozen of load testing metrics.

“With Stacktical, you get double the insight for half the effort. The platform already plays a big role in our daily Capacity Planning routine.”

We’re currently running a private beta program with dozens of DevOps, startups and other companies around the world on bringing new features, improving existing ones and ultimately strengthen the value of Stacktical for them.

And we still have a few seats available if you’re interested.

What’s your take on this? 📣

What about you? What’s your take on Capacity Planning and how would you face something as challenging as handling a South by Southwest like audience?

Follow and engage with @willitscale on Twitter, Facebook or Google+ (Or drop us an email here)

Scale well until then,

Founders at Stacktical

--

--

Stacktical Team

Hi, we're the team behind Stacktical and the DSLA downtime compensation token.