On Scaling
17 Jan 2020 by Dave
A relatively common question I get in interviews is whether we’ve ever had issues with scaling. I mean, we are web scale, right?
I did some rough calculations, and we’d need a client base 32 times larger than we have today to get to the point where simply switching to a larger DB server every time we need additional scale might stop working. (Even Stack Overflow uses a single DB server). At our current growth rate of 60% per year, that gives us 7.4 years. At that point, the company would be very valuable, and it would be easy to put together a whole team dedicated to scaling. In fact, we may get away with just adding some caching layers at that point. We are definitely not one of those companies that uses problems envisioned 7 years down the line to choose today’s technologies.
Now, I get the appeal of working on some service that gets 100,000 requests per second or stores petabytes of data. Those are some impressive numbers! (sometimes people tell me I sound sarcastic even when I don’t intend to be. But I seriously mean this. No, really). But why would someone think your average SaaS company has any of that? If we ever reached 60Tb of data the company would be worth close to a billion dollars - a 100% verified fact because that’s what it says on the back of the envelope I calculated it on.
I think the web is to blame for this. People love stories like “how we reached web scale by using technology X”, “Rails doesn’t scale” and “How to serve a million requests per second using [insert flavour of the week here]”. It’s great when technology meets its intended purpose. If you’re Facebook, you need massive storage. If you’re WhatsApp (before they became part of the Facebook borg) you want tech that reliably handles large connection counts without breaking the budget. Just remember that no-one writes blog posts like “How we built a valuable company with Rails and a fault-tolerant Postgres setup”, or at least no-one’s reading and sharing them. Our primitive monkey-brains crave novelty, not run-of-the-mill ordinary success.
For 99% of SaaS companies, infrastructure should be simple and stay out of your way. We hire software developers to work on the core value we deliver, which is… software. Not infrastructure. There are far more interesting technical issues to be solved, like delivering great features and finding a way to keep your code base from turning into a ball of mud as you expand it. Apart from that, a way more important scaling consideration is scaling of the team itself. Every developer added increases the complexity of the development process, and I think that’s an interesting non-technical challenge to work on.
Just today, a candidate told me that working with a very large number of servers is important to him because it “gives him adrenalin”. Well, I get enough satisfaction from solving problems for our growing, profitable client base. If you need adrenalin from your infrastructure then please don’t apply for a job at our company. We don’t want to deal with the added excitement.