The Implications of Live Notifications

There is a trend among web 2.0 websites to add live chat or notifications to their websites. I have had the opportunity to work with a couple of them – one specialises in a product that provides such live chats to websites; the other is creating notifications and IM-like behavior for users browsing their pages.
Facebook of course added live notifications – you can see which of your friends are online and send them messages. Google has Gtalk purely on the web. This post analyzes the problems with such notifications.

Structure of Live Notifications

A chat or notification feature typically requires polling the web server. The user's browser has to go back to the server to check for any messages. It also writes the user's messages for other people. Such polling is done using Ajax webservice calls so that the user does not notice it.
Take the example of GTalk (Google's online chat). There are several webservices in that application:
1. when user logs in there is a notification POST saved in their data store so that user's contacts can see him/her online
2. when user logs in there is a "GET" to get the user's contacts who are online
3. when user types a message for a contact it is POSTed to that contact
4. when the contact types a message, the user's client GETs new messages addressed to him/her.
5. when user logs out there is a notification POST so that his/her contacts do not see him online
6. the user can also change their online status - that is a POST

Of these, items 2 and 4 require the user's client to constantly poll the server at a system-configurable interval. If this interval is high (say 2 minutes), the user gets frustrated. If it is low, the server takes a huge hit.

Implications of Live Notifications

Adding such notifications to a website requires careful analysis. The reason is because of the constant polling and writing data, Live Notifications increase the workload of a public website.
In a website there may be hundreds of online users - they may be going through different pages. The number of online users at the same time is called simultaneous user count. But the webservers themselves may be taking a lower hit - since many of the users may be reading content and otherwise browsing through a page, the number of concurrent users will generally be lower than the number of simultaneous users. Therefore a website can afford to have an infrastructure that supports a certain number of concurrent users. A set of concurrent users translates to a set of threads executing or waiting at the same time in a web server.
But, if the website introduces Live Notifications, the usage pattern changes dramatically. The constant polling makes the number of concurrent users close to the number of simultaneous users. Thus even if the the number of users in that website has not changed, the servers may be in for a beating.

This may not happen in a desktop IM client like Yahoo! Messenger - desktop IMs can afford peer-to-peer communication and therefore will not affect servers to the extent that a web model does.

Solutions for Live Notifications

The bottleneck in a Live Notification feature is the database server. Since conversation histories have to be stored, and every contact around the world should be able to send messages, database writes are unavoidable. They go up heavily in such a scenario. But the real problem is database reads. These may cost a server and a normal running server may crash if you add Live Notifications.
The web server is usually stateless in such interactions and thus scaling by adding more would work.

There are generally different levels of investment needed for companies deploying such features.

1. If your online (simultaneous) user base is low (say 2000-5000 users online at a time), you may be able to get away with a stateless webserver talking to a dedicated database server.

2. If your online user base is in the tens of thousands, you cannot afford reads to hit the database. You would need a solution in the middle-tier like memcached. This would keep the user's messages in the middle-tier and enable polling to retrieve new messages from the memory instead of the database. You will need a set of servers talking to a memcached server. You will also need failover for the memcached server.

3. If your online userbase is in the hundreds of thousands, you may need clusters of servers in the middle-tier and a complex addressing scheme so that messages can be picked up from a server. This is heavy investment in infrastructure, maintenance and engineering.

If your user base is low, then consider sticking to solution 1.
Before directly stepping into solution 3 ask yourselves this question - is adding such notifications a critical feature needed by my website? It is a specialty area.

Javascript Libraries

When you are designing an application there are several paths regarding the choice of UI:
1. If the application is internal to an enterprise, you can choose a desktop application. Mostly instead you choose an application delivered through the browser to avoid installations. Even through the browser, you have options like .NET Smart Clients that are opened in the browser. You have the option of Flash/Flex or Silverlight - a consistent, rich UI experience with Drag/Drop is possible in this environment. You can also choose traditional JSP or ASP.NET applications with postbacks.
2. If the application is facing public users, then most of the above options are eliminated - you have to go with Javascript/HTML/CSS - because it is the paradigm of the web.

In both the above cases, there is a reluctance to choose Javascript to build strong UI - the reason is that Javascript programming is not very type-safe. Editors are hard to come by. There is little use of intellisense. It is still seen as just a "scripting" language. In the browser, there are still cross-browser issues in DHTML, Ajax and so on.
I wrote a post sometimes back about Object Oriented Javascript - mainly talking about simple OOJ concepts. But in the past few years, almost every month someone releases a Javascript library. Javascript libraries such as prototype are immensely popular for a few good reasons:
1. Cross-browser issues are transparently handled by these libraries
2. They provide standard controls, layout managers and a great programming model.
3. They also provide means of extending such controls using OOJ.
4. They provide a custom Event model.
Thus, developers and architects dealing with decisions on web based delivery should necessarily consider Javascript libraries. Since there are hundreds of them, you should be aware of a few considerations while choosing one:
1. The libraries size matters - prototype.js is small, but UI effects needs libraries like scriptaculous. These can add to the size of the HTTP response - but can be easily managed by web server compression and caching headers. The libraries also come in a "minified" form for deployment.
2. Some of them come with complex controls that you can then extend to create your own. They are proper frameworks. You may choose them based upon your UI needs.
3. Select a library that has a popular user base. JQuery, Dojo, scriptaculous, mooTools, and the now-popular ext-js all have a good user base. Do NOT expect, though, very high level documentation.
All of these libraries provide services such as:
1. Cross-browser DHTML
2. Ajax
3. Common Controls such as trees, accordion
4. Drag and Drop and other effects that work cross-browser
5. JSON and XML support

So, if you are considering an internal or external facing website consider Javascript programming using one of these libraries. It makes life a lot simpler. You gain all of the services by including the necessary javascript files in your header.
(Also knowing one of these libraries provides a fast path to knowing others).

To start exploring, download one of these libraries and go through the tutorials. It does not take much time to figure out (particularly if you know OOJ).