The only change I would make to the "stages" is to add caching up front. Most modern web frameworks make the use of caching pretty trivial therefor making it less of a pain than setting up load balancers and multiple web servers, etc. Static content should also make use of caching headers and be served by a separate server than dynamic content; this is also a trivial improvement.<p>Having only a single web server, database server, and static content server while making liberal use of caching and smart querying result in benchmarks indicating we can sustain around 1900 req/sec. Even if that isn't entirely accurate, the chances of us reaching the 82 million page views per month to find out is all but inconceivable.
Great post! It points out up front that performance != scale.<p>The other scaling point is concurrency. You can't (for example) serially add features to a page. Eventually that page will simply take too long to render.<p>A lot of "dashboard" pages suffer from this problem. If you reach that stage you need to start thinking about decoupling features - using things like messaging.
I agree on many points like performance and scalability are not the same but his traditional approach to just make a bigger clustered database is not good. It's like fixing the bottleneck by making a gigantic bottle, it'll work but the cost will be many times over what was really necessary.<p>If a any single component is a critical bottleneck the best is to either replace it or redesign to stop requiring it.<p>Same goes for the more memory approach.
There's something weird about reading an August 2008 presentation that says "Source Control: RCS, CVS, Subversion" -- right between slides mentioning "64-bit" and "cloud computing".<p>I haven't used CVS in at least 5 years, and I've never even seen RCS in use. Part of me wonders if RCS is Rackspace's secret weapon.