title: server-side caching strategy for user filtered results
body: <p>I have a situation at <a href="http://www.zipstory.com" rel="nofollow">www.zipstory.com</a> (beta) where I have n-permutations of feeds coming from the same database. For example, someone can get a feed for whatever city they are interested in and as many of these cities all together so its all sorted by most recent or most votes.</p>
  
  <p>How should I cache things for each user without completely maxing out the available memory when there are thousands of users at the same time?</p>
  
  <p>My only guess is don't. I could come up with a client-side caching strategy where I sort out the cities results but this way I could still cache in a one-size fits all strategy by city.</p>
  
  <p>What approaches do you suggest? I'm in unfamiliar ground at this point and could use a good strategy. I noticed this website does not do that but Facebook does. They must be pulling from a pool of cached user-feeds and plucking them in client-side. Not sure, again I'm not smart enough to figure this out just yet.</p>
  
  <p>In other words...</p>
  
  <p>Each city has its own feed. Each user has an n-permutation of city feeds combined.</p>
  
  <p>I would like to see possible solutions to this problem using c# and ASP.NET</p>
  
  <hr>
  
  <p>Adding to this Febuary 28th, 2013. Here's what I did based on your comments so THANKS!...</p>
  
  <ul>
  <li>For every user logging in, I cache their preferred city list</li>
  <li>The top 10 post results are cached per city and stored in a Linq based object</li>
  <li>When a user comes in and has x cities as feeds, I go through their city list loop then check if city postings are in cache, if not, I get from DB then populate the individual posting's html into cache along with other sorting elements.</li>
  <li>I recombine the list of cities into one feed for the user and since i have some sorting elements on the linq object, i can resort them in the proper order and give back to the user</li>
  </ul>
  
  <p>This does mean there is some CPU work everytime regardless as I have to combine city lists into a single city list but this avoids going to the database every time and everyone benefits in faster page response times. The main drawback is since I'm not doing a single query UNION on cities before, this requires a single query per city if each was not cached but each city is checked if cached or not individually so 10 queries per 10 cities would only happen if the site is a dead zone.</p>