It's a combination of Moore's law and churn, since the site is reasonably effective it generates huge churn. Since RAM follows Moore's law you could always kee

It's a combination of Moore's law and churn, since the site is reasonably effective it generates huge churn. Since RAM follows Moore's law you could always keep the users in RAM if you wrote effective queries because user growth didn't outpace Moore's law. All you had to do was build a server big enough. C# definitely helped vs ruby, the real kicker was stored procs, everything was a highly tuned stored proc. The huge insights I got was latency, by keeping everything close together you could run some really abysmal synchronous code with out cratering everything. Also, he really cared about the ant hill more than the ants. He would do horrible things to the ants that would encourage them to build a bigger ant hill. (Ants are users, employees were treated very well) As a fictional example, lets say the site was skewing too heavily male by 20%, just add a line in the stored proc that gave a male user a 20% chance of their registration not being written to disk. Voila, site has the proper mix, onto the next problem. He was the most brutally effective person I've ever worked with.