Kind of a fascinating post on the technical challenges Twitter faces. Here’s the final graph from part one:

The social web is creating demand for new scaling tools and technologies. Current databases and caching solutions are simply unable to handle a complex network of multiple relationship between objects. While databases are still a good solution for persistent storage of social data, each retrieval requires heavy calculation. These are the exact challenges Nouncer is attempting to solve and commoditize in the microblogging space. In the short run, an “inbox” approach to scaling microblogs might be the logical approach, but in the long run we have some exciting problems to solve.

Since I showed up grudgingly and late to the Twitter party, I’ve surprised myself by getting into it as much as all the fankids did when it came out a couple years ago. And I’ve definitely seen some pretty decent-sized service outages just in the couple weeks I’ve been messing with it. After getting into Cal Henderson’s Building Scalable Websites and working on a Rails-based social networking app for a client earlier this year, I’ve been thinking about the various problems involved in scaling, and it occurred to me that Twitter had to have some pretty major issues, even before I started to experience them myself. The sheer fact of the access abilities that Twitter gives you – I hit it on a regular basis with my iPhone, Adium, and an Apple Script that ties in with Quicksilver and Growl – means that you’re going to end up with a vast quantity of people expecting real-time results nearly 24×7.

That ability to do the whole Twitter dance from a multitude of devices and protocols is what got me into it (I would never have even signed up if I had to log in somewhere every time I wanted to change my status), and it also has to be a huge part of the general challenges they’re facing. The barrier to entry is set low enough to challenge a limbo champion, the app becomes super-popular, and suddenly, like it or not, you’re on the forefront of the challenges involved in web scaling.

Seems pretty obvious from today’s post on dev.twitter.com that they’re well aware of standing in the gaze of tech history, too. And kudos to them for being so honest about their challenges. It’ll endear them to the already massive community of geeks who love their service and hate their downtime, and it’ll no doubt spur some quality engineers to answer their call for help. I was especially impressed by Al3x’s honesty in this graf (even if the things he’s saying are pretty obvious):

Our direction going forward is to replace our existing system, component-by-component, with parts that are designed from the ground up to meet the requirements that have emerged as Twitter has grown. First and foremost amongst those requirements is stability. We're planning for a gradual transition; our existing system will be maintained while new parts are built, and old parts swapped out for new as they're completed. The alternative – scrapping everything for "the big rewrite" – is untenable, particularly given our small (but growing!) engineering and operations team.

Make no mistake about it, Twitter is definitely in a race against time to make sure that they’re not overtaken by the multitude of clones out there. But this level of honesty about their approach to the problem is only going to end up strengthening the case they make to their users to stay with them through the growing pains.