How key-based cache expiration works

The post argues that manual cache invalidation is error-prone and that key-based cache expiration is a cleaner approach. In this scheme, the cache key changes together with the object it represents, usually through a timestamp in the key, while the cached content itself stays fixed.

It also says dependency chains should update their timestamps together so related keys change at the same time. Caching then happens in views through nested partials, and old cache entries are left behind because Memcached can evict them when needed.

Reading notes

#

• manual cache invalidation is described as frustrating and easy to get wrong
• the cache key changes, while the cache content stays fixed
• the key is tied to the represented object, often with a timestamp such as class/id-timestamp
• when the object changes, new content is written to the new key
• old cache entries become garbage and are not manually cleaned up
• Memcached evicts old keys when space runs out
• dependency chains are handled by updating updated_at across related model objects
• Rails cache calls can nest through partials and use cache_key on array elements