this is by no means the final partition, but I propose using this as the first one, as it allows you to cache and further partition generic data and remove all the overhead of authentication and SSL without any special analytics. With user-specific data, even if it is stateless, things become a bit tricky.

If there is no authentication required by business rules to access such data, then I’d “cheat” and push that as well into generic data servers if possible. For example, personal pages on social networking sites may be considered user specific at first glance, because they are related to a particular user, but they are in fact generic because everyone can access the same details. The site can store your user ID in a cookie and then forward you to the correct profile when you click on “My page” link without touching the database. There is no harm if I see your page, as long as I cannot change it without authentication.

If authentication to view the data is required by business rules (for example in a typical e-commerce application) then caching that data and exposing it directly would be considered a huge security gap. So this data stream has to go though SSL and be protected by proper authentication. Putting it in the same cache as other data would only complicate things for the rest of cache. Depending on business rules, this may be cached as well, but under the umbrella of user specific services. That way the generic data stream remains simple.