Unicorns and Scalability

Unicorn road sign

There’s been so much talk recently about performance and scaling thanks to Twitter and I really want everyone to shut up about it.

“Language Foo can scale better than Bar!”

“If only they had used language Baz!”

Pay attention to this part because I’m only going to say it once:

Your code doesn’t scale, your architecture does.

I’ve been reading about scalability for a while now and participated in a few highly-trafficked websites and I can say that the language that we used was the least of our concerns. And it would probably be trivial no matter what language we chose.

Every time I’ve ever heard someone talk about scaling issues, I don’t hear them talk about the raw execution time of their code. It’s always about disk I/O, database performance or network capacity.

When I interviewed at Insider Pages a few years ago they never mentioned Ruby or Rails as a limiting factor, it was databases and their network. A nice blog comment about Insider Pages mentions scalability tactics.

When Scribd talks about scaling with Rails, you don’t hear them mention Ruby. It’s all about adding databases and caching. (Please remember Rails is a framework (an architecture for your code) and Ruby is a language).

Flickr talks about scaling a lot [PPT] and they don’t mention PHP. They mention database sharding, caching and capacity planning.

Even Twitter’s status blog never mentions Ruby as their bottleneck. They mention database and database, load balancing and caching . Blaine Cook’s presentation about scaling Twitter mentions databases and caching. (I know, I know, he left Twitter, but his comments are still spot-on with common scaling issues.)

Yahoo’s former engineer Jeremy Zawodny has an old presentation on scaling PHP and MySQL and he never mentions PHP as the bottleneck.

So remember kids, when you are thinking about scaling, think about your architecture.