Cache the Stable, Resolve the Exact

"Cache what changes slowly. Never cache the one thing your result must be exactly reproducible from."

Two kinds of simulation input, two caching rules

A simulation needs two very different kinds of input, and Keep treats them oppositely. Calibration — derived quantities like volatility, beta, and anchor values — is cached for a day. Seed prices — the exact starting prices each run begins from — are always resolved fresh at run time, never served from cache. Same run, two inputs, two rules: one cached, one always live. The split isn't arbitrary; each rule follows from what the input is for.

Why calibration can cache

Calibration is derived and stable. Volatility and beta are computed from windows of historical data; they describe the character of an instrument, and that character doesn't meaningfully change from one hour to the next. Recomputing them on every run would be pure waste — expensive work to arrive at essentially the same numbers. A one-day cache matches their real tempo: they're stable enough that yesterday's calibration is a fine input to today's run, and caching them keeps simulations fast.

Cache by tempo: the slower something truly changes, the safer it is to cache. A cache TTL is a claim about how fast a value moves. Derived, slow-moving quantities like volatility earn a long cache; the exact instantaneous inputs that a result must be reproducible from do not. Match each value's cache lifetime to how fast it actually changes — and to how much its exactness matters.

Why seed prices must be fresh

Seed prices are the opposite kind of input: they're the exact anchor a run's whole fan of paths grows out of. If a seed price came from a cache, two runs "from the same starting point" might silently start from slightly different prices depending on cache state — and the run would no longer be exactly reproducible from its recorded inputs. So Keep resolves seed prices fresh every time and persists the resolved value with the run. That way the run's starting point is both exact at creation and captured for replay. The thing your reproducibility hangs on is never left to cache luck.

Fresh-then-persisted is the key move. Seed prices are resolved live at run time AND stored with the run. Live-at-creation guarantees an exact starting point; stored-with-the-run guarantees you can replay it later. Neither alone is enough — a cached seed wouldn't be exact, and a fresh-but-unstored seed couldn't be replayed. Resolve fresh, then persist.

Code

Opposite caching rules for opposite input roles (illustrative)·python

def prepare_run(inputs):
    # Calibration: derived and stable -> a 1-day cache is fine.
    calib = cache.get_or_compute(
        "sim_calibration", inputs.tickers, ttl=24 * 3600,
        compute=lambda: derive_vol_beta_anchor(inputs.tickers),
    )

    # Seed prices: the exact starting point -> NEVER cached.
    # Resolved fresh at run time, then persisted WITH the run so the
    # run stays exactly reproducible from its own record.
    seed_prices = resolve_prices_now(inputs.tickers)   # live, uncached

    return {**inputs.__dict__, "calibration": calib, "seed_prices": seed_prices}

Exercise

In any computation with multiple inputs, classify each input as 'slow-moving and safe to cache' or 'must be exact and captured for reproducibility.' Pick one of each and justify the classification. Then describe the bug that appears if you cache the input that should have been resolved fresh — specifically, how two runs that should be identical could silently diverge.

Hint

The dangerous mistake is caching the exact anchor a result is reproducible from. If the starting value can come from a warm or cold cache, two 'identical' runs start from different places depending on timing — and now your reproducibility guarantee is a coin flip. Slow-and-derived caches safely; exact-and-anchoring must be fresh.

Cache the Stable, Resolve the Exact

Two kinds of simulation input, two caching rules

Why calibration can cache

Why seed prices must be fresh

Code

External links

Exercise

Progress

Comments 0