Cool! I agree on the "good to know people with similar problems" I can see why aggregation of the data can be such a challenge for you. My suggestion revolves

Cool! I agree on the "good to know people with similar problems" I can see why aggregation of the data can be such a challenge for you. My suggestion revolves around a smart client that can do aggregation through (for eg) javascript on in a browser. Our system is actually polling under the hood (that is how "Comet" works) but our backend never sees the polls. You have a good point about open sockets being another problem. Fortunately it is thoroughly solved by messaging servers, for instance http://www.rabbitmq.com/ http://www.rabbitmq.com/ - it handles tons of connections so your backend doesn't have to. Your requirements are a great fit for a single threaded server such as node.js, twisted or so on that uses that whole polling model rather than many threads. You could have (say) a twisted server that receives messages from the backend on rabbitmq, interprets and aggregates and then forwards to your clients. The send to clients happens via another publish of a message to RabbitMq on a different channel and is un-affected by the number of users watching. But like you said, solved problems are not worth a whole bunch of engineering effort when things are still running just fine. Just throw more hardware at it and move on to selling what you have. :)