rails-caching-strategy

Rails Caching Strategy

Cache the right thing at the right layer. AI agents reach for Rails.cache.fetch on any slow code path, oblivious to the cache layer above (HTTP), the cache layer below (DB query cache), and the cost of cache invalidation. Caching is the second-hardest thing in computer science — get the layer wrong and you'll have stale data, mysterious bugs, and a 2am page.

Why this matters

A cache is a contract: "this value is fresh enough for N seconds." Pick the wrong N, the wrong scope, or the wrong key, and you ship a bug that's invisible until users complain. Rails gives you four good caching tools — each is right for one situation.

The opinion

Greenfield Rails 8: Solid Cache for the cache store, no Redis just for caching. Add Redis only when you need pub/sub or are co-locating with Sidekiq. HTTP caching at the edge (CDN) when it fits — biggest win, lowest cost. Fragment caching for view partials that repeat. Low-level (Rails.cache.fetch) for computed values keyed by something you control. Always: fix the query first.

Counter-positions:

• Redis as cache — still legitimate for ultra-high-throughput sites or when you already run Redis for jobs. Solid Cache is plenty for most.
• Memcached — historical default. No reason to pick over Solid Cache or Redis in 2026.
• Caching is the answer — sometimes. The first answer is "fix the N+1, add the index, profile the SQL." Caching covers what's left.

The cache hierarchy

┌────────────────────────────────────────────┐
│  L0: CDN / edge cache (Cloudflare, Fastly) │  ← Best — never hits Rails
│  L1: HTTP cache (Cache-Control headers)    │  ← Browser + reverse proxy
│  L2: Page cache  (rarely used now)         │
│  L3: Action cache (rare)                   │
│  L4: Fragment cache (view partials)        │  ← Most common
│  L5: Low-level cache (Rails.cache.fetch)   │  ← For computed data
│  L6: DB query cache (per-request, automatic)│  ← Rails handles this
└────────────────────────────────────────────┘