This is a Guest Post by Keith Hanson.

Most of my Plurk buddies know that I’ve been working furiously on a desktop client for Plurk.com. The UI of Plurk is absolutely amazing, and much thought has obviously gone into making the Plurk micro-blogging experience a better one, as well as providing more of a community feel.

While working on my application, I have discovered a few reasons why Plurk functions well under the high load of all the messages passing through it, as KDFrawg has already pointed out. So, for those that wish to know, I wanted to give you an inside look at the way Plurk’s user interface works, and why it will most likely be able to handle the load much, much better than Twitter.

I’ll be using a few technical terms in this article. For this reason, an understanding of AJAX would be helpful, but not critical. Simply put, AJAX is a background web request that runs behind the scenes while you’re looking at a page. Think of it all as the JavaScript of that page going out and asking for information without you having to do anything. When I say something like, “An AJAX call is made to /Notifications/getCount”, it’s as if you were doing that for yourself, but a JavaScript function did it for you.

While building my application, I’ve noticed that Plurk’s user interface is very efficient in it’s use of AJAX calls (you can watch these yourself with FireFox and a plugin called FireBug).

While looking at your page, there are a few things that get updated frequently and automatically. All of your stats, for instance, get updated every now and again, as do your friends list, your karma, your response and plurk counts, etc. Also, you’ll see often that you have new and unread plurks waiting for you. All of these things are being updated by behind-the-scenes AJAX calls.

For instance, examples of things that occur on your page while you’re just sitting there looking at your page are:

1) Every now and again an AJAX call is made to /Notifications/getCount. This AJAX call returns a number, which is the number of current Alerts that you have. It happens pretty infrequently though, which is why you will often see your Alerts get out of sync with how many you *actually* have.
2) A Little more frequently, an AJAX call to /Users/getUpdateableData occurs and updates things like your Karma (if it has changed, of course), response count, and your plurk count. This is the information in the box below your Timeline.
3) Very frequently, /Timeline/getPoll occurs. Which, very simply, returns the new plurks and unread plurks. It returns the IDs of the new Plurks and Plurks with Unread content. A few other calls go out to actually fetch the content.

Also, when you click “Update” after seeing an alert that you have new plurks, a /Timeline/getPlurksById occurs, which takes a specific number of ids as a parameter, and returns only those exact plurks. This means you don’t have to reload the entire timeline to get only the new plurks.

Also, each plurk returned returns it’s response count, as well as how many responses you’ve seen. Since responses aren’t fetched until you actually click on a Plurk, there’s a very very low amount of traffic going across your internet connection.

For instance, for a typical /Timeline/getPoll, this response is returned:

{”new_plurks”: [], “unread_plurks”: [];

Basically, that’s saying there’s no new plurks and no unread plurks. Compare that with Twitter’s API, where you basically get the latest 20 plurks every time. Every single time you ask for an update with your client.

So, because of smart AJAX calls, plus good forethought and planning, I’d say that we’ll only be seeing Plurk go down for upgrades and/or feature updates, and not because it is overwhelmed by the traffic.