Thanks for sharing your experiences. With commonly used processes (like memcached and sphinx search) and normal client libraries, I have not found a substantia

Thanks for sharing your experiences. With commonly used processes (like memcached and sphinx search) and normal client libraries, I have not found a substantial increase in time to architect and configure. You are right about time to administer, but in my experience that is front-loaded, and the added ease of troubleshooting problems readily offsets it. By hide, I mean you still have services that your domain logic is consuming, but they appear to be part of your business application in a mono-process architecture instead of being "exposed" in SOA. If adding servers is painless and automated, then I disagree that there is a substantial difference between 2 and 10. If you want to have fast recovery, reproducibility and transparency, a cluster of 2 servers takes almost as much effort as a cluster of 10. Tuning applications doesn't add nearly as much to the bottom line as feature development does, especially early on in the start-up. Twitter is an obvious example of not performance tuning fast enough, but 1000x times that are examples of scalable websites we'll never hear of[1]. The conventions and convenience of "mainstream" rails architectures make this SOA approach nearly painless. However, I do agree that rails is obnoxiously slow. To me, this is a huge problem in your average response time more than total throughput of the architecture. Further, I think we agree that scaling is not a problem, until it is a problem. One thing you may not be aware of is that in the ruby world, sphinx and memcached are actually easier to use than their in-process equivalents. Further, the tendency in the rails world to go with MySQL rules out all the awesomeness of Postgres.