Most of the responses here focused on the disk/data aspect. What about the actual network? IPv4/TCP has a minimum overhead of 40 bytes per packet, with a seve

Most of the responses here focused on the disk/data aspect. What about the actual network? IPv4/TCP has a minimum overhead of 40 bytes per packet, with a seven packet overhead for the connection itself (three for making a connection, four for closing the connection). Adding another packet for the actual data (with say, a payload of only 20 bytes) and that's about 220 incoming bytes across 5 packets (two from the client for the connection, one for the data, and two for closing the connection---I'm concentrating on the incoming side as outgoing should be similar). Multiply 220 bytes by 10 to get a rough estimate of bits per second (close enough and makes the math a bit easier and if we're a bit high here, that's better than being too low) times the number of connections per second (16,667) gives us around 37Mbps---a T3 basically. Now, to handle a potential 100,000 users at the same time, that's 6 T3s (12 if you want to handle 200,000), and that's with only 20 bytes of actual data being shipped between client and server. Just the networking side is going to be expensive, so I hope the idea is a good one. One the data storage side, I worked on a project (http://www.x-grey.com http://www.x-grey.com) where I had to potentially store a bunch of records. I ended up storing them all in memory in an array. When a new record came in, I would insert it into the proper spot. In theory, I was able to handle about 6,000 requests per second on a 2.6GHz machine (although I found it rather difficult to actually test it properly, which is why I say in theory---in practice it may be more or less, but for what I was doing, that was way more than good enough). So yes, I would recommend keeping everything in memory and avoid the disk as much as possible. But then you have issues of coherency if you have multiple threads/machines that need to update this structure (in my case, that 6,000 is ONE CPU doing the work; I sidestepped the whole concurrency issue by ignoring it).