Load balancing, as part of ensuring high availability and acceptable response times, is mostly a server-side architectural technique. Yet, as rich-client and Ajax applications push increasing amounts of application logic to the client, some load-balancing techniques have become available on the client as well. A recent article by Lei Zhu, Client Side Load Balancing for Web 2.0 Applications, explains one such technique:

What are the advantages of using client-side load balancing over server-side load balancing? The obvious advantage is that a special load-balancing device is unnecessary—there is no need to configure load-balancing hardware, or to make sure that the backup functions the same as the primary load balancer.

The key in Zhu's technique is simply to provide to the client a list of alternative servers to contact. The client can randomly choose any of the servers to communicate with. Further, the available servers list can be loaded at runtime from a highly reliable network location. Zhu points out that the advantage of this technique is that reliably serving the single file listing available servers is a much easier task than alternative server-side load balancing techniques:

It is easier to make the client code and resources highly available and scalable than to do so for the servers—serving non-dynamic content requires fewer server resources. In addition, it is possible to put the client code on a highly reliable distribution service such as Amazon Web Services’s S3 service. Once we have client code and resources served from a highly reliable location, let us take a look at how we can load balance server clusters.

Since the client will have to connect to hosts other than the one serving its initial resources, Zhu points to various ways to deal with browser security restrictions:

In order for the load-balancing scheme ... to work, the client code at www.myloadbalancedwebsite.com needs to be able to call services running on other sub-domains (such as s1.myloadbalancedwebsite.com)...

XHR strictly forbids client calls from a different domain to the server. Luckily, a workaround exists if the client and server have the same parent domain—as in our example, www.myloadbalancedwebsite.com and s1.myloadbalancedsite.com. We can make all AJAX calls to the server using an iframe loaded from the server; since browsers allow communication between scripts in an iframe, it is possible to access data received from the server calls made in the iframe if the scripts are loaded from the same parent domain. Problem solved.

What do you think of Zhu's client-side load balancing technique?