Enterprise Rails

Chapter 12. Materialized Views

When you are not caching anything, every page load incurs the penalty of the queries required to make up that page. Initially, when you do not have much data and you do not have many users requesting pages, your application will be snappy. Unfortunately, with any amount of success, you eventually get hit with three problems seemingly all at once:

• Your application becomes popular and the traffic you need to handle has grown by orders of magnitude.

• As you sign new customers, gather data, and even simply exist, the amount of data in your database grows by orders of magnitude.

• Your application grows in complexity and more queries are required to render any given page.

Although most people would be envious of these problems (and the business side of your company would term them “successes”), you nonetheless have to find solutions.

Caching—the act of saving a queried or calculated result for future use—is not as simple and clear-cut as it sounds. A number of subtle issues surround correct caching, which go beyond picking a cache key and storing data in the cache behind that key. The first issue is freshness. Can your cache lag behind the true values of your data, or does it need to reflect the latest values? Next is correctness. If your goal is to keep the cache up-to-date, have you accounted for every situation where your cache needs to be invalidated or rebuilt? How do you know you’ve hit all of these cases? The final caching issue you must be aware ...