You'd be surprised how much one can run off one server should the application not need a lot of reads. Every single user page should be able to be cached until

You'd be surprised how much one can run off one server should the application not need a lot of reads. Every single user page should be able to be cached until the user posts again. Likewise, the page of any post should be able to be cached infinitely. They don't run their messaging queue off their database I'd assume. Really, Twitter doesn't do relational data which makes scaling a good bit easier. The small amount of relational data that they do could be easily denormalized and pushed into memcached. The problem that a lot of web apps face is that it's hard to denormalize because so much of the data is relational. The only relations that I can think of is Person follows Person and Post belongs to Person and Post replies to Person. So, it's not hard to denormalize that in a way that you can push into memcached rather than having to hit the database much. I'm not saying that's how I'd do it if I were building Twitter, but with minimal relations and a small amount of data it's easy enough to keep the MySQL store in memory for log(n) lookups from memory and use memcached for O(1) lookups for the majority of stuff.