Solid Cache: database caching
This course follows how one Rails application caches with Solid Cache, a store backed by the database. It covers when caching makes sense, the six fragment caches and their multi-part keys, and how versioning on updated_at retires old entries without manual clearing. It contrasts this with a Rails.cache.fetch value that expires after five minutes. It then inspects the SolidCache::Entry table and explains why the cache moved to its own database while the queue and cable stayed in the primary one.
What you'll learn
- ✓The four conditions a cache bets on, and what not to cache
- ✓Why each element of a multi-part fragment cache key is there
- ✓How cache_key and cache_version let entries retire themselves
- ✓Caching a Ruby value with Rails.cache.fetch and expires_in
- ✓What the SolidCache::Entry table stores and how reads are batched
- ✓The trade-offs of moving the cache to its own database
What this application caches, and why
A cache is a bet more than a speed trick. It bets that some work is expensive to produce, cheap to store, requested repeatedly, and acceptable when slightly out of date. All four have to hold. When one of them doesn't, caching makes the system worse in a way that's hard to see.
Read the full lesson free →Curriculum
7 lessonsWhat this application caches, and why
Covers when caching pays off, the seven places this app caches, and why fragments and stats expire differently.
Every element in this app's multi-part cache keys
Explains why locale, sign-in state and per-student progress values each appear in this app's array cache keys.
How this app's cache entries retire themselves through versioning
Shows how a fixed cache_key plus an updated_at version and template digest retire entries without manual clearing.
Rails.cache.fetch: caching a value instead of HTML
Caches an admin stats Data object with a hand-written string key and a five-minute expiry instead of versioning.
SolidCache::Entry: the one table that holds every cache value
Inspects the SolidCache::Entry table, its columns, its byte_size totals and the batched key_hash reads on the roadmap.
Why the cache got its own database
Explains why the cache got its own database for backups and disposability, and what that split costs.
Putting it together: from a live page to a row you can inspect
Traces a roadmap card from its cache key to its row and closes with a plain Ruby key challenge.