I spent time untangling the caching stack in a recent project, and the main thing I came away with was this:   
Most cache bugs are not performance bugs. They’re consistency bugs.  
We ended up with a layered model because one cache was not enough, and “faster” was not the same thing as “correct”:

  \- sessionStorage for tab-local state

  \- localStorage for synchronous cold-start UX

  \- IndexedDB for durable browser persistence

  \- in-memory refs and Maps for streaming hot paths

  \- Redis for cross-device shared state

  \- Durable Objects for live execution snapshots

  \- CDN caching for public pages with stale-while-revalidate and stale-if-error

What mattered most was not the storage engine. It was the contract. For every cache layer, the key questions were:

  \- Who owns the source of truth?

  \- How stale is acceptable?

  \- What invalidates it?

That’s what shaped the implementation. A workflow canvas can restore instantly from IndexedDB, but it must never let stale local state overwrite the backend once the authoritative load arrives. A live execution state can live in a Durable Object and survive reconnects, but it should still be pruned when it’s clearly dead.

A public template page can be CDN-cached, but if the backend is slow, stale content is better than a broken screen. So the actual architecture lesson was this:

Caching is not a speed trick. It is a consistency model with a latency budget.

Caching is a consistency model with a latency budget