The eternal scalability war: a profile

The issue of scalability seems to be an eternal debate among on web technology weblogs. Some say that it is now more important than ever. Others increasingly frequently and loudly call for slaying it. Naturally, some calls are more reasoned than others. Some people interject to say that everyone has scalabity problems. Heated arguments unfold every time someone offers an opinion.

The opposing camps in the debate can be broken down roughly like so:

• If you don’t manage to scale to hundreds of thousands of users with near-perfect uptime, you’re toast.
• If you attempt to scale to hundreds of thousands of users with near-perfect uptime, you’re toast.

Sure, I agree with the “scalability is a liability” crowd in that a vast majority of successful businesses will never need to serve that many customers, and that even if they eventually have to, expending the effort up front before they know they will grow to be a success like that is a bad investment. This is certainly true. And every time I read yet another article that makes these points, I am left with a bad taste in my mouth. Is the answer really to ignore scalability completely? Of course not. Most of these screeds end with a note to the effect that you probably can’t build a business on slow, messy, unmaintainable code. But no one makes a suggestion on how to draw the line whose existence everyone seems to be aware of.

What we have here is another polarised debate with no constructive resolution. What’s the point? Especially puzzling is that the productive answer never comes up. It isn’t terribly obscure, after all:

Know how far you can scale, and how close you are to that breaking point. Be aware how much load your application is handling with how much resource consumption. Project how much more load it would be capable of withstanding, and how quickly you’re likely to reach that limit based on current customer acquisition rates (and leave a little breathing room for the unexpected, but don’t bet too much on it). If you’re getting close, know which resource is in shortest supply and find ways to address the bottleneck as effectively and cheaply as possible.

Does that sound familiar? It should, to any programmer. There isn’t much magic to it. It’s age-old “profile before you optimise” wisdom. Once you put things in this light, it’s clear that shooting for extreme scalability and uptime is just another instance of the age-old premature optimisation trap.

There is no need to make a debate of such epic proportions out of the issue.

Can we please get back to work now?