The people at Twitter - you know, the web service that lets you send SMS-length "microblogs" to the world, or particular people, or just one person - must be bracing themselves. Next week is the Apple Worldwide Developers' Conference, where Steve Jobs will address the adoring masses. Of developers. Of whom, you can be sure, many will be on Twitter, sitting with fingers poised over their laptops or (inevitably) iPhones waiting to tell an information-hungry world what's just been said. Twitter is thus guaranteed to fall over at some point during Jobs's speech.
Not that that will make much difference: Twitter users are increasingly inured to outages.
Why should a service that's been around for a couple of years still have these problems? As Jack Dorsey and Biz Stone, two of its founders, noted in a blog post earlier this week, every new tweet (a single message) gets written on to one MySQL database; that is then replicated to multiple slave databases, from which all the "reads" (outputting the tweets to the world, or those parts of the world that want to know them) are taken. From a design point of view, sensible. (And far better than a "decentralised" service, potentially a consistency nightmare.)
The problem comes from exponential growth. "Twitter is, fundamentally, a messaging system," explained Alex Payne of Twitter in another blog post. "Twitter was not architected as a messaging system, however. For expediency's sake, Twitter was built with technologies and practices that are more appropriate to a content management system."
Well, that's your problem right there. More to the point, because Twitter is so Web 2.0-y, and lets anyone hook into it through its well-exposed (and simple) application programming interface (API), scores of services have sprung up which leech on it. Quotably, Tweetscan, Tweetstats, Tweeterboard - while they might not be what's killing Twitter, they aren't helping. There's an excellent explanation, from an outsider who built a Twitter-like system, of the problems with scaling it: basically, every single Twitter user's view on every refresh is different from every other user's view. And it changes much, much faster than, say, Facebook (also built on MySQL).
What Twitter needs is to expand its capacity while making money from those who are using it. True, it has just received $15m (£7.5m) of venture capital funding, valuing it at $80m. But it needs to deter some people from using it - while benefiting from those who continue to.
There are two obvious ways forward. Charge the users, or charge those who want to get at the users. The first option is fine - if it wants to lose 90% of its user base (the rough tradeoff any service sees if it begins charging, however little). The second option might look puzzling, but it has worked before, in the MP3 market.
Once, there were zillions of MP3-playing software programs. Then Fraunhofer, which owns the patents, decided to charge for their use. At a stroke, the number of MP3 encoder/decoders shrank - leaving only those companies able to pay for them.
Twitter could do the same: charge for access to its API, or throttle requests over a certain limit from non-paying sources. True, its architecture challenges would remain - but with money coming in, it would have the incentive to get it right. And in the end, what do you want: a Twitter that's free, or a Twitter that works?