(I'm not a ZP employee, but I have worked in environments of significant scale a fair amount. The below is just my opinion...) #1: The usual approach is someth

(I'm not a ZP employee, but I have worked in environments of significant scale a fair amount. The below is just my opinion...) #1: The usual approach is something like remove app servers from the load balancers' rotation, upgrade them, run some sort of tests to ensure the upgrade is ok, add them back into the LB rotation. Some environments might use user traffic as the test step (e.g. send 5% of your users at the newly upgraded machines, watch monitoring to see how response times and error counts behave). #2: The answer here really depends on what scale you're operating at. DB replication (e.g. read slaves if your traffic is more read-heavy that write heavy) and sufficiently high-spec machines combined with intelligent use of caching can take you a fairly long way. I hesitate to give hard numbers, but off the cuff probably 99% of sites will never need more than this. There's not really a recipe to follow for that, the data needs and design/ops parameters of an organization tend to be fairly specific to that org; more or less it's good schema design, thinking hard about how fresh data has to be at the edge, caching what you can with careful management of expiry times, and having an ops team comfortable with managing replication. Beyond that scale you start getting into globe-spanning multiple-datacenter voodoo rocket science. :) Ask amazon, google or facebook (some of their work has been mentioned publicly, things like cassandra from fb and various papers published by google/amazon).