Thanks for your thoughts, and I don't disagree with the general philosophy you're pitching. I think, though, you may be imagining something different than I'm

Thanks for your thoughts, and I don't disagree with the general philosophy you're pitching. I think, though, you may be imagining something different than I'm trying to describe. It seems that you're thinking in terms of front end and back end servers and a cache that is seperate severs, which is why you suggest that the cache in the nodes serving the authoritative data should be sufficient. I'm describing a system whereby there is only one server configuration and it contains the whole stack and thus to increase capacity you add more servers, which means more cache, more database capacity, etc. This may be non-traditional, but it is amenable to an ec2 type of setup where you scale the cluster up or down without having to keep ratios of types of servers and their connections coordinated. I don't intend to change the cluster size, except to slowly add more servers over time. But having different types means different configurations, and keeping it coordinated. The idea here is, one type, it is already configured, it is actually an image and you just clone it. Didn't realize that memecahced worked that way, I do need to look into it more, and thanks for the alternative recommendations. There are some elements, like images that appear on every page, or CSS files, that will be served much more than others, I can store all these elements in the couch, and maybe they will live in ram due to the systems virtual memory, making explicit caching pointless. I will need to do tests here, you are right. But I was going by some previous experience and common "best practices" advice to try and explicitly keep some of this in ram. Further, I do want ot keep some operational state information in ram, so that it can be written often, even though it doesn't need to be persisted, but does need to be read by multiple machines in the cluster. Anyway, I appreciate your suggestion, and agree with the desire to keep complexity down. One of the ways I'm doing this is to have a single machine type, thus no complex heirarchy of machines that have to be configured to work with each other. Just add additional nodes to add capacity.