More Twittering

If there's one way to describe Twitter so far it's slow. I guess that's a good sign for them. I'm going to assume they must have a lot of traffic making them so slow. Let's hope it's not light traffic making them slow.

If you think about it though, you could probably consider Twitter to be a "high transaction" environment. A lot of people compare Twitter to IM clients, but it's really a lot different from a technical perspective. All the "tweets" are sent to the server and persisted (presumably in a database.) Hence the "transactions".

The other fun side must be sending out the updates to followers. There's two obvious ways to architect such a thing: pull or push. For pull, each user logged in would have some list of people they are following. A proxy for that user would have to constantly poll the server to see if there are any new updates. In push, you keep track of the people following each user. So if a user sends in an update, it needs to be pushed to the user's followers.

There are problems with either track, and typically an asynchronous pub-n-sub system would be used for something like this. Maybe Twitter does that. The trickiest part would be determining the subscribers. These would be people logged in on the website, obviously. But it would also be people with IM established and logged on to their IM (I guess they could try to send the IMs regardless if people are logged in or not.) Ditto for SMS. I guess if any of those criteria are met, then you could create a virtual subscriber for receiving updates and then relaying them appropriately. Of course you'll need a scheduler for creating these virtual clients, since one can turn off their SMS updates during certain hours of the day, etc.

Actually I think I would even turn the message persisting into a subscriber. That fits well with the AJAXy interface for it. You send a message and it goes into a queue. A subscriber representing your buddy picks it up and send it to your buddy's phone. Another subscriber representing a persistent store picks it up and saves it to tweet database. Seems pretty slick.

Yep, seems like it could be a fun system to put together. You've got to love a consumer site with lots of database transactions and asynchronous message queuing. Of course if I assume they did put the system together with lots of asynchronous parts, then it really better be bandwidth that's making them so unbearably slow. All the better reason to use IM or SMS for send/receive updates I suppose...