Realtime is a thing that has two meanings, what you call 'realtime' is not really realtime, which means 'when it happens', but more of a softer version of it.<p>To make the distinction, consider 'hard' realtime, where the events are very closely followed, usually with a guaranteed latency between something occurring and a response.<p>Twitter and all kinds of other 'realtime' applications are probably better described as 'near realtime'.<p>To make a website that displays 'live' data you can use ajax for underwater calls to see if the data on the page has been updated since the last time you related it.<p>Plenty of sites now use this technique, and while it gives you the impression that it now really is 'realtime' the only difference really is that you no longer do the poll to see if new information has arrived, your browser does it for you.<p>The web being 'pull', in other words you contact a server to retrieve information short of keeping an HTTP connection open all the time and streaming data through it as it becomes available you have to perform some kind of poll. And, as you already noticed this is pretty inefficient.<p>If you use server-push, which is technically possible - and which I've been using in some form or other since the mid 90's to stream 'video' (read a sequence of still images) - the upper limit is usually how many concurrent connections your server architecture can handle.<p>For a single machine with a single IP that upper limit is about 60,000 connections, a multi-homed machine can do a multiple of that by binding to more than one IP address. The reason for this is that every connection requires a socket which maps to a port and the TCP field for a port number is only 16 bits.<p>By using a poll system the overall latency goes up but you can handle many more concurrent users with the same machine.