Understanding predictive caching

Traditional caches are reactive — they only store something after it's been requested at least once. Glacier is predictive: it tries to have the data ready before the first request.

Reactive vs. predictive

A normal cache follows a simple rule: fetch on miss, serve on hit. The first user to request something always pays the full latency cost, because there's nothing cached yet. Popular data stays warm; everything else is cold on first touch.

Predictive caching flips the order. Glacier watches how users actually move through your app — which routes follow which, which queries cluster together — and uses those patterns to warm data ahead of the request. Done well, the "first miss" largely disappears.

How predictions are made

Glacier builds a lightweight model of access patterns from three signals:

• Sequence — what tends to be requested right after what (e.g. opening a list then a detail view).
• Recency — how recently an entry was touched, which decays over time.
• Co-occurrence — entries that are frequently requested together within a short window.

When confidence that an entry will be needed crosses a threshold, Glacier prefetches it and holds it warm for the configured ttl.

Where warming happens

With edge: true, prediction and warming run at the edge location nearest the user. That means warmed data sits physically close to where the next request will originate, removing both the compute round-trip and the network distance.

What Glacier does not do

Glacier is a caching layer, not a data store. It never becomes the source of truth — your API or database still owns the data. If a prediction is stale or missing, Glacier transparently falls back to the underlying fetch, so the worst case is simply the behavior you'd have without it.

Next, see Predicting user behavior for how to give Glacier hints, or jump to the API reference.