Myth: Scaling is a good problem to have
Not Yet
People often say that scalability is something you should ignore until it starts becoming a problem.
“You don’t have a scaling problem yet.”
…it is best to not worry about it too much until it starts becoming a problem.
That’s true, but scaling is still…
Not Easy
“Admittedly, this is a good problem to have (because customers love Optify and keep the data flowing) and it is fun to scale the system to give our clients a responsive application.”
Some people think scaling is fun. I wholeheartedly disagree. I’d much rather be building and shipping product.
No One Said Scaling Was Easy
But you might think that way if you read something like this:
“Will my app scale when millions of people start using it?”
“Ya know what? Wait until that actually happens. If you’ve got a huge number of people overloading your system then huzzah! That’s one swell problem to have. The truth is the overwhelming majority of web apps are never going to reach that stage. And even if you do start to get overloaded it’s usually not an all-or-nothing issue. You’ll have time to adjust and respond to the problem. Plus, you’ll have more real-world data and benchmarks after you launch which you can use to figure out the areas that need to be addressed.”
So here are some important points about scaling that are not so obvious but are subtly implied:
- It’s usually not an all-or-nothing issue, but it definitely could be, depending on your app and the nature of what’s causing the scaling problem.
- You’ll have time to adjust and respond to the problem, but only if you have a lot of resources, are operating efficiently, understand how to quickly modify your system, and expend a lot of effort on responding to issues as they arise. Also, you need to proactively and continuously monitor and modify your app.
- You’ll have more real-world data and benchmarks, but only if you set them up, have good profiling tools handy, know how to use them, and put in the time to analyze the results. And this only helps if you actually act on them, which sounds simple but could be insanely hard.
“Did we experience any problems? A few. But we also realized that most of the problems we feared, like a brief slowdown, really weren’t that big of a deal to customers. As long as you keep people in the loop, and are honest about the situation, they’ll understand.”
- We had problems that turned out to be “not a big deal” for us, but we were incredibly lucky, communicated closely with our customers, and had a clear and viable business model that made this all work.
- Scaling is really hard if you didn’t write the code yourself, or if you don’t intimately understand how the problematic part of the system works.
But I still agree with this:
“In the beginning, make building a solid core product your priority instead of obsessing over scalability and server farms. Create a great app and then worry about what to do once it’s wildly successful. Otherwise you may waste energy, time, and money fixating on something that never even happens.”
But not this:
“Believe it or not, the bigger problem isn’t scaling, it’s getting to the point where you have to scale. Without the first problem you won’t have the second.”
Big Problem – And It Killed Me
Getting to scale is a problem, but it’s not the “bigger” problem. They’re both huge problems. Tons of sites have been killed by scaling problems. Friendster is the most famous example, but my previous site was also killed by scaling problems.
It was called Invision Plus, and it was a forum hosting service. We had millions of users and millions of monthly pageviews. At one point we were ranked in the Alexa top 400.
All of those bullet points above? Not something my startup had the resources to do.
Undeniably, my previous website was killed by millions of people using it.
Scale the right thing
But if you do need to scale, one important thing to remember is that you might not have to actually scale the feature. Maybe you can just remove it. With Friendster, one problem was:
“The continued insistence by PM that calculating the 3 or 4 degrees of friends total had to be part of the main feature list. A huge amount of time, effort, and hardware was spent on keeping these supposedly important numbers updated real-time.”
Make sure your team and servers are expending resources doing the right things.
“You have to revisit anyway”
“The fact is that everyone has scalability issues, no one can deal with their service going from zero to a few million users without revisiting almost every aspect of their design and architecture.”
—Dare Obasanjo, Microsoft (from Scaling Up and Startups)
No Single Solution
“Scaling a database can be a real problem. While it may be a good problem to have (since it means your database and traffic are growing – typically reflecting growth in business), it’s bad news from an operational and technical standpoint. It’s critical to resolve scalability issues before the database is entirely overwhelmed, and what makes it even more problematic – is that there isn’t a single solution for all your scalability hurdles.”
“There’s no one-size-fits-all solution for scalability, and each service or configuration available in the market addresses scalability in a different way. It’s up to you to make sure the MySQL scalability solution you end up with matches your specific DB scaling requirements.”
Yep – Scaling is a big problem and it’s definitely not always good. It might very well kill you.
Hi there – Do you want to possibly guest blog for me in June alongside 100 other tech companies? Take a look and lmk.
[…] is directly proportional to the amount of users you have. Scaling issues become a so-called “good problem to have†as it usually means your app has a lot of traction. If these are paying users, even […]