Cache
Play this lessonThis lesson comes with an interactive animation you can break, a live-code challenge and a chapter quiz.A cache is a temporary store, kept in memory, for expensive or frequently used data. Memory is much faster than a database, so repeated requests come back quickly. A separate cache tier also takes load off the database and can be scaled on its own.
Read-through caching: the web server checks the cache first. If the data is there (a hit), return it. If not (a miss), query the database, save the result in the cache, then return it. Memcached and Redis expose simple calls like cache.set("key", "value", 3600) and cache.get("key").
Things to think about
- When to use it: for data that is read often and changed rarely. Cache memory is volatile: a restart wipes it, so never keep important data only in the cache.
- Expiration: give entries a time to live (TTL). Too short and you hammer the database; too long and data gets stale.
- Consistency: the database and the cache aren't updated in a single transaction, so they can disagree. Doing this across regions is especially hard (see Facebook's "Scaling Memcache" paper).
- Failures: a single cache server is a SPOF. Use several across data centers, and overprovision memory to leave a buffer.
- Eviction: when the cache is full, something has to go. LRU (least recently used) is the most popular policy; LFU and FIFO are alternatives.
Key takeaways
- Hit = fast memory read. Miss = slow DB read, then store it.
- Set a TTL, plan for eviction (LRU), and watch out for stale data.