The amortization inequality is the "natural batch size" in a new costume

When does a derived cached object pay, and why does fan-in kill it?

The inequality from The governing arithmetic (where viability is set by the read/write ratio, not read volume) applies to any derived cached object (a result, a view, a metadata snapshot). Recall P (cost to produce one version), S (saving per read served), λ (read rate), w (rate of invalidating writes to the dependency set).

A version lives 1/w on average and serves λ/w reads. Its value is (λ/w)·S − P. The cache pays iff

Two more things become precise.

First, fan-in degrades the threshold linearly. Fan-in is the number of dependencies. With n dependencies, the effective write rate is w_eff = Σwᵢ (the sum of each dependency's write rate), so reads per version is λ/Σwᵢ.

This is the arithmetic behind the derivation ladder: the further derived the object, the larger its saving S and the larger its Σwᵢ, and the second usually wins. It also shows why metadata caching is the best deal in a data lake (λ is huge, there is one dependency, and commits are rare) and why broad result caching over a streaming table is worthless, however you configure it.

Second, and this is worth keeping: P/S is a natural batch size, with reuse count as the batch. A fixed cost per operation always gives a natural batch size, the amount of work you must spread it over before the mechanism pays. Here the fixed cost is P, the per-unit saving is S, and P/S is the minimum number of reads that must share the fixed cost. It is the same algebra as the index-maintenance decision (is it worth keeping an index for the number of reads?), the compress-or-not decision (is the CPU cost repaid by saved I/O?) and the materialization break-even (is a precomputed table worth its storage?): four costumes, one arithmetic.

In one sentence: λ/w > P/S; fan-in adds Σw and kills derived caches; the threshold is the natural batch size with reads as the batch.