This is more of a "point me in the right direction" question.

My team of three and I have built a hosted web app that queues and routes customer chat requests to available customer service agents (It does other things as well, but this is enough background to illustrate the issue).

The basic dev architecture today is:

• a single page ajax web UI (ASP.NET MVC) with floating chat windows (think Gmail)
• a backend Windows service to queue and route the chat requests
  • this service also logs the chats, calculates service levels, etc
• a Comet server product that routes data between the web frontend and the backend Windows service
  
  • this also helps us detect which Agents are still connected (online)

And our hardware architecture today is:

• 2 servers to host the web UI portion of the application
• a load balancer to route requests to the 2 different web app servers
• a third server to host the SQL Server DB and the backend Windows service responsible for queuing / delivering chats

So as it stands today, one of the web app servers could go down and we would be ok. However, if something would happen to the SQL Server / Windows Service server we would be boned.

My question - how can I make this backend Windows service logic be able to be spread across multiple machines (distributed)? The Windows service is written to accept requests from the Comet server, check for available Agents, and route the chat to those agents. How can I make this more distributed? How can I make it so that I can distribute the work of the backend Windows service can be spread across multiple machines for redundancy and uptime purposes? Will I need to re-write it with distributed computing in mind?

I should also note that I am hosting all of this on Rackspace Cloud instances - so maybe it is something I should be less concerned about?

Thanks in advance for any help!