Twittering About Architecture
dev.twitter.com
dev.twitter.com
I attended Railsconf 2007 and two of twitter's developers held an impromptu session to discuss the scaling challenges they faced. Twitter had just experienced several days of downtime and the room was filled with people interested in hearing all about it. It was pretty obvious from that one hour session that their issues are more than just technical.
At one point they showed some code that was used to balance some of their load among a group of servers. Unfortunately they wrote the function in such a way that it was limited to a maximum of 10 servers. Once they exceed the capacity of those 10 servers the whole site came crashing down. They seemed like nice guys and were excited about their work but it was obvious based on their comments and the crowd's reaction that they were out of their league. I got the impression that they are doing whatever it takes to keep the site up and running today, even if it brings the site down tomorrow.
Slides from the session I referenced: http://www.slideshare.net/al3x/scaling-twitter-railsconf-200...
http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi...
I have a Jabber bot running that is hooked into the entire public timeline and it continues to run even when the main website has gone down. I don't think you can directly compare Twitter's issues with issues of Meebo, AIM, GTalk, etc.
Erlang makes distribution and concurrent execution semantically identical, Scala doesn't. And there doesn't seem to be a good reason to base on the JVM, they aren't already next deep in Java libraries.
I'd really like to know what they're thinking over there.
The mindset for selecting tools to build apps which need to scale seems be similar to the one we all had back in early dos days, when the company programmers were having to write all the internal software. We were either unaware of better solutions or we simply felt compelled to write all the stuff ourselves, from spreadsheets to a GL module. Now, with all the customizable apps around, why would anyone want to write a custom GL module?
By extension, why try to reinvent solutions for scaling problems when Erlang already does a bunch of the work for you?
But we've had e-mail working fine for years, and Twitter is just e-mail.
I'll leave the armchair architecting to others.
People who read sites like TechCrunch most definitely know what Twitter is, and coverage that talks about why they have scaling problems as opposed to making a soap opera about it is very useful for that demographic.
But people like to act like Twitter owes them something. Fact is, it's a free service.
In the spirit of building their business they clearly want -- in fact they need -- to build the best product they can; the fact that it's taking too long by our estimation doesn't matter. They're not going to leave money on the table so you can believe they're working hard to fix the problem and start working on their revenue model.
Kudos to the Twitter team for returning critical volleys from some in the tech community without losing their cool.
- Re-writing their whole system incrementally will be expensive; I think they might need google money and brains to complete the whole thing... or a lot more than 15mm.