The Fastest Query Is the One You Never Run: The Four Layers of Rails Caching

Rails Performance: Lessons from Production — #4

The first three posts were about making queries cheaper — fewer N+1s, indexes, not dragging data back into Ruby. This one flips the angle: the fastest query is the one you never run. Compute a result once, store it, and hand it to everyone after. Same example throughout (a shipments table), walking through the four layers of Rails caching: compute, invalidate, render, transfer.

🔥 The same 800ms stat, recomputed for every visitor

The homepage shows a "courier shipment ranking." It's heavy — scanning a few million shipments and a GROUP BY takes 800ms.

The thing is: that number looks the same to every user, and it doesn't need to be real-time (a few minutes stale is fine). But our code makes every visitor recompute it from scratch — 800ms each. Under traffic, the DB gets ground down by the same calculation over and over.

That's the sweet spot for caching — expensive (worth saving) and hit repeatedly (the same result is reused). Let's start from the most basic tool.

Continuing the four layers from #1: the first three posts optimized "how data is fetched"; caching is "don't compute what you already computed." One idea runs through the whole post — use updated_at as a "version," reuse while the data hasn't changed.

📦 Layer 1 (compute): Rails.cache.fetch

Wrap that 800ms calculation:

Rails.cache.fetch("courier_ranking", expires_in: 5.minutes) do
  Shipment.group(:courier_id).count   # the heavy calculation
end

What fetch does, in one line: if it's there, take it; if not, compute it and store it.

• First time: look up key → miss → run the block (800ms) → store it with a 5-minute expiry → return.
• Next 5 minutes: look up key → hit → return the stored value, the block never runs (milliseconds).

So the first user pays 800ms, everyone else for the next 5 minutes gets it free.

Two key parameters:

• key ("courier_ranking"): the cache's name. If the result varies by condition, the key must encode that, e.g. "courier_stats/#{courier.id}".
• expires_in: how long until it expires, i.e. "how stale can you tolerate." Shorten it for fresher data.

When is something worth caching? ① Expensive — high recompute cost, worth saving. ② Hit repeatedly — the same result is used many times (across users, or the same query requested over and over).

As for "freshness" — that's not a precondition, it's a problem to solve: tolerate some staleness → use expires_in; need it current → use key-based invalidation so it updates the moment data changes (the next layer is exactly this).

🔑 Layer 2 (invalidate): key-based expiration

expires_in only handles "time's up," not "the data changed." You set 5 minutes, but a new shipment lands in between, and users see a stale number. How do you make the cache "update the moment data changes"?

❌ The dumb way: manually delete the cache when data changes

after_commit { Rails.cache.delete("courier_ranking") }

Problem: you have to remember "which operations affect which caches," and clear each one by hand. With many caches it becomes a nightmare — miss one and you've got a stale-data bug. This is the origin of the famous line "cache invalidation is one of the two hard problems."

✅ The smart way: put the "version" in the key, so the key changes when the data does

Rails generates a key for each record that changes with updated_at:

courier.cache_key_with_version
# → "couriers/1-20260626120000"   ← the trailing part is the updated_at timestamp

Use it as the cache key:

Rails.cache.fetch(courier.cache_key_with_version) do
  expensive_render(courier)
end

• courier unchanged → key unchanged → hit (old value) ✅
• courier modified → updated_at changes → key changes → miss → recomputed automatically ✅

You never manually delete anything — when data changes, the old key is abandoned and the new key naturally computes the new value.

Mindset: don't "clear the old cache," let "a data change produce a new key." That notorious cache-invalidation problem mostly disappears.

🪆 Layer 3 (render): fragment + Russian Doll

So far we cached computed results. But sometimes computing the data is fast and the slow part is rendering it into HTML (lots of ERB, helpers). Here what you cache is the rendered HTML fragment.

Fragment caching: wrap a chunk with cache in the view:

<% @couriers.each do |courier| %>
  <% cache courier do %>          <%# automatically uses courier.cache_key_with_version as the key %>
    <div class="courier-card">
      <h3><%= courier.name %></h3>
      <p>Shipments: <%= courier.shipments_count %></p>
    </div>
  <% end %>
<% end %>

• First time → miss → run ERB to produce HTML → store it.
• After → hit → return the stored HTML directly, ERB doesn't run.
• courier modified → key changes → only that chunk re-renders.

Russian Doll caching: nested — an outer cache wrapping inner caches, like a matryoshka:

<% cache courier do %>                  <%# outer: courier card %>
  <h3><%= courier.name %></h3>
  <% courier.shipments.each do |shipment| %>
    <% cache shipment do %>             <%# inner: each shipment %>
      <%= render shipment %>
    <% end %>
  <% end %>
<% end %>

The clever part is "change one, re-render only one." Change a shipment → only that inner card re-renders; the outer courier card also reassembles, but the unchanged shipments' inner cards come straight from cache, so reassembly is just stitching existing HTML — fast.

For "change a shipment → outer courier updates too" to work, the inner change must propagate up:

class Shipment < ApplicationRecord
  belongs_to :courier, touch: true   # a shipment change also touches the courier's updated_at
end

touch: true makes the inner change bump the outer key, which is what makes the whole Russian Doll work.

Why is touch needed? Because an outer cache hit returns the whole stored HTML wholesale — it never re-checks the inner caches. So if the outer key doesn't change, you'd serve stale inner content. touch forces the outer to miss and reassemble (pulling unchanged inners from cache).

🗄️ Where the cache lives (cache store)

Where Rails.cache stores things is decided by the cache store, and the production choice matters:

The key point: production usually has multiple servers / workers. With memory_store, the cache server A computed isn't visible to server B — effectively not shared. So use Redis / Memcached, a centralized store, so the whole system shares one cache.

# config/environments/production.rb
config.cache_store = :redis_cache_store, { url: ENV["REDIS_URL"] }

🌐 Layer 4 (transfer): HTTP caching (ETag)

The earlier layers save "recompute," but the server still assembles and sends the response. HTTP caching goes further — when data hasn't changed, don't even send it:

def show
  @courier = Courier.find(params[:id])
  fresh_when(@courier)   # computes an ETag (version fingerprint) from updated_at
end

• On response, the server includes an ETag header; the browser remembers it.
• On the next request, the browser automatically sends "I have this version."
• The server compares: unchanged → returns 304 Not Modified with an empty body, the browser reuses its own copy; changed → normal 200 + new content.

What it saves is bandwidth and transfer — when nothing changed, just a tiny 304 instead of re-sending the whole page.

🏁 Wrap-up: the four layers of caching

All four share one underlying idea:

Use updated_at as a "version" — reuse while data is unchanged, auto-update when it changes.

The biggest trap in caching isn't "how to store," it's "how to keep it from going stale." Remember key-based — don't clear caches by hand, let the key follow the data's version — and that infamous cache-invalidation problem is mostly solved. But don't swing the other way and cache everything either: first confirm the thing is genuinely "expensive + reused," then cache it, or you've just added complexity and a "why am I seeing stale data" debugging nightmare.

📌 This post is about how caching works. But caching's real difficulty is in the failure modes you hit after it ships — hammering the DB the instant a key expires (stampede is just the appetizer), a whole code path breaking when the cache disappears, an unbounded key set blowing up memory, even faithfully storing an error. Those "you only learn it by getting burned" traps are in the follow-up: We added a cache; three days later it took the database down at peak.