I'm sure by now the Twitter team must be very aware of what their bottlenecks are. I don't know what the typical user Twitter user does. I personally send 1-5 m

I'm sure by now the Twitter team must be very aware of what their bottlenecks are. I don't know what the typical user Twitter user does. I personally send 1-5 messages per day but refresh the web timeline all the time. If most people are like me, then I would want to keep the last 24-48 hours worth of messages in memory. This shouldn't be a problem, as we are talking about 1M messages times 200 bytes or so, uncompressed. In order to generate a page, you'd need a "follow" matrix. Given a user, you want to know who this person is following and pick up enough recent messages to generate a page view from the memory table above. This "follow" matrix would be relatively sparse (I imagine). It must be persisted often but given that it's queried all the time it would have to be in memory as well, at least partially. Assuming that Twitter has 2M users and the average user follow 40 people (wild guess), the entire matrix would take up 80M ids (a few hundred megabytes in a hashmap or something). Also, I'd cache personal timeline requests for a minute or so, to avoid being killed by people hitting Ctrl-F5. Of course the devil is in the details. All that information needs to be persisted and crash-recoverable. For the numbers above everything might work on a single beefy server but probably not for long, so the system has to distributable. It's not an easy problem, but a competent team should be able to solve it (perhaps not in the most elegant and cleanly documented way) in a matter of weeks given the right motivation. Getting the system to be stable enough for production would be a different matter.