{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiboiduaufirti2ghah44mlf5cr5kkpnn4tgvg53ggi64kq7tcuarq",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpadwpki2eq2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihxf2ozw57kajqaz2mkz4hrw2kg6xzj6pdqoqlgpj67fkvffm7lmu"
    },
    "mimeType": "image/webp",
    "size": 66598
  },
  "path": "/danewu/the-fastest-query-is-the-one-you-never-run-the-four-layers-of-rails-caching-fif",
  "publishedAt": "2026-06-27T01:38:31.000Z",
  "site": "https://dev.to",
  "tags": [
    "rails",
    "performance",
    "caching",
    "redis",
    "1",
    "We added a cache; three days later it took the database down at peak",
    "@couriers.each",
    "@courier"
  ],
  "textContent": "> **Rails Performance: Lessons from Production — #4**\n>\n> 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.\n\n##  🔥 The hook: the same 800ms stat, recomputed for every visitor\n\nThe homepage shows a \"courier shipment ranking.\" It's heavy — scanning a few million shipments and a `GROUP BY` takes 800ms.\n\nThe 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.\n\nThat'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.\n\n> 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.\n\n##  📦 Layer 1 (compute): `Rails.cache.fetch`\n\nWrap that 800ms calculation:\n\n\n\n    Rails.cache.fetch(\"courier_ranking\", expires_in: 5.minutes) do\n      Shipment.group(:courier_id).count   # the heavy calculation\n    end\n\n\nWhat `fetch` does, in one line: **if it's there, take it; if not, compute it and store it.**\n\n  * First time: look up key → miss → run the block (800ms) → store it with a 5-minute expiry → return.\n  * Next 5 minutes: look up key → hit → **return the stored value, the block never runs** (milliseconds).\n\n\n\nSo **the first user pays 800ms, everyone else for the next 5 minutes gets it free.**\n\nTwo key parameters:\n\n  * **key** (`\"courier_ranking\"`): the cache's name. If the result varies by condition, the key must encode that, e.g. `\"courier_stats/#{courier.id}\"`.\n  * **`expires_in`** : how long until it expires, i.e. \"how stale can you tolerate.\" Shorten it for fresher data.\n\n\n\n**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).\n\nAs 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).\n\n##  🔑 Layer 2 (invalidate): key-based expiration\n\n`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\"?\n\n**❌ The dumb way: manually delete the cache when data changes**\n\n\n\n    after_commit { Rails.cache.delete(\"courier_ranking\") }\n\n\nProblem: 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.\"\n\n**✅ The smart way: put the \"version\" in the key, so the key changes when the data does**\n\nRails generates a key for each record that changes with `updated_at`:\n\n\n\n    courier.cache_key_with_version\n    # → \"couriers/1-20260626120000\"   ← the trailing part is the updated_at timestamp\n\n\nUse it as the cache key:\n\n\n\n    Rails.cache.fetch(courier.cache_key_with_version) do\n      expensive_render(courier)\n    end\n\n\n  * courier unchanged → key unchanged → hit (old value) ✅\n  * courier modified → `updated_at` changes → key changes → miss → recomputed automatically ✅\n\n\n\n**You never manually delete anything** — when data changes, the old key is abandoned and the new key naturally computes the new value.\n\n> Mindset: don't \"clear the old cache,\" let \"a data change produce a new key.\" That notorious cache-invalidation problem mostly disappears.\n\n##  🪆 Layer 3 (render): fragment + Russian Doll\n\nSo 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**.\n\n**Fragment caching** : wrap a chunk with `cache` in the view:\n\n\n\n    <% @couriers.each do |courier| %>\n      <% cache courier do %>          <%# automatically uses courier.cache_key_with_version as the key %>\n        <div class=\"courier-card\">\n          <h3><%= courier.name %></h3>\n          <p>Shipments: <%= courier.shipments_count %></p>\n        </div>\n      <% end %>\n    <% end %>\n\n\n  * First time → miss → run ERB to produce HTML → store it.\n  * After → hit → **return the stored HTML directly, ERB doesn't run**.\n  * courier modified → key changes → only that chunk re-renders.\n\n\n\n**Russian Doll caching** : nested — an outer cache wrapping inner caches, like a matryoshka:\n\n\n\n    <% cache courier do %>                  <%# outer: courier card %>\n      <h3><%= courier.name %></h3>\n      <% courier.shipments.each do |shipment| %>\n        <% cache shipment do %>             <%# inner: each shipment %>\n          <%= render shipment %>\n        <% end %>\n      <% end %>\n    <% end %>\n\n\nThe 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.\n\nFor \"change a shipment → outer courier updates too\" to work, the inner change must propagate up:\n\n\n\n    class Shipment < ApplicationRecord\n      belongs_to :courier, touch: true   # a shipment change also touches the courier's updated_at\n    end\n\n\n`touch: true` makes the inner change bump the outer key, which is what makes the whole Russian Doll work.\n\n> 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).\n\n##  🗄️ Where the cache lives (cache store)\n\nWhere `Rails.cache` stores things is decided by the cache store, and the production choice matters:\n\nstore | where | use\n---|---|---\n`:file_store` (the default when unset) | local disk files | single machine; not shared across machines\n`:memory_store` | a single process's memory | lost on restart, not shared across workers — **don't use in production**\n`:redis_cache_store` | Redis | ⭐ the production mainstream, shared across servers\n`:mem_cache_store` | Memcached | pure-cache scenarios\n`:solid_cache_store` | the database (default in new Rails 8 apps) | when you don't want to run a separate Redis\n\n**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.\n\n\n\n    # config/environments/production.rb\n    config.cache_store = :redis_cache_store, { url: ENV[\"REDIS_URL\"] }\n\n\n##  🌐 Layer 4 (transfer): HTTP caching (ETag)\n\nThe 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** :\n\n\n\n    def show\n      @courier = Courier.find(params[:id])\n      fresh_when(@courier)   # computes an ETag (version fingerprint) from updated_at\n    end\n\n\n  * On response, the server includes an **ETag** header; the browser remembers it.\n  * On the next request, the browser automatically sends \"I have this version.\"\n  * The server compares: unchanged → returns **`304 Not Modified`** with an **empty body** , the browser reuses its own copy; changed → normal `200` + new content.\n\n\n\nWhat it saves is **bandwidth and transfer** — when nothing changed, just a tiny 304 instead of re-sending the whole page.\n\n##  🏁 Wrap-up: the four layers of caching\n\nlayer | tool | what it saves\n---|---|---\ncompute | `Rails.cache.fetch` | recomputing expensive work\ninvalidate | key-based (`cache_key_with_version`) | the pain of manual cache clearing\nrender | fragment / Russian Doll | re-rendering HTML\ntransfer | HTTP caching (ETag) | even the send (304)\n\nAll four share one underlying idea:\n\n> **Use`updated_at` as a \"version\" — reuse while data is unchanged, auto-update when it changes.**\n\nThe 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.\n\n> 📌 **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**.",
  "title": "The Fastest Query Is the One You Never Run: The Four Layers of Rails Caching"
}