A derived entry has a dependency set

Why does climbing the derivation ladder raise what an entry saves while lowering how often it can be used?

CaseConstructed case · Ifeoma at Dawnpost

The result cache that stopped working

The editors' dashboards run SQL over the Parquet warehouse. Ifeoma added a result cache, and on weekdays it works very well. Then the data team switches one important table to streaming ingestion, with a new file committed every 10 seconds. The result-cache hit rate for that table drops to almost zero, and no setting brings it back.

At the same time a trivial "show the schema of this table" call takes 200 ms, because it goes through the catalog. And a misconfigured crawler asks for article IDs that do not exist, millions of them, and every such lookup walks all the way down to the database before it returns "not found".

Three symptoms, three kinds of cached object. To see why each behaves as it does, we need to open the cached object up.

How it ends →

What makes data cacheable treated the cached object as opaque: a thing with a reuse distance, a size and an invalidation rate w that was simply given. Now w is the thing being designed. Opening the object up shows the constraint that generates this whole article:

The organizing dimension is derivation distance: how far the cached object sits from the base data. As you climb the ladder, three quantities move.

S, the saving per hit, rises: you skip more work.
w_eff = Σwᵢ, the invalidation rate, rises: more dependencies, each with its own write rate.
λ_eff, the share of traffic that can hit this specific entry, falls, because specificity rises. A cached file block serves every query that touches it. A cached query result serves only a byte-identical query from the same user in the same session context.

The third one is the one that actually kills things. Put these against the amortization condition λ_eff / w_eff > P / S. Climbing the ladder improves the right-hand side (S rises) and attacks both terms on the left. Derived caching is squeezed from both ends of the same inequality. This is why the naive move, "cache the final answer, it saves the most", is usually the worst available choice.

Once you see the squeeze, the rest of the article organizes itself: every mechanism above the file-block level is an attempt to break one of the three couplings.

Semantic caching attacks the collapse of λ_eff.
Incremental view maintenance attacks the cost of w_eff rather than w_eff itself.
Metadata caching is the one place where all three happen to be favourable at once.
Negative caching is a degenerate case with P ≈ 0 and S maximal, so it passes the bar easily and fails for a completely different reason.

The ladder in one table

Object	What must match for a hit (sets λ_eff)	Dependency set (sets w_eff)	P	Coupling it breaks	Escape when it fails
File / block	offset and identity	none, if the file is immutable	~0	none needed	content-addressed key
Result	query text + plan + session environment + user	every input table, at any row	high	none: worst case on all three	version-fingerprinted key
Metadata	table identity only	one commit to that table	~0	all three are favourable	split mutable pointer from immutable body
Materialized view	a query the rewriter can match to it	every input, but repairable incrementally	very high	the cost of w_eff	algebra permitting delta maintenance
Semantic fragment	subsumption, not equality	as a view, plus a decidability limit	high	the collapse of λ_eff	sound-but-incomplete syntactic test
Negative entry	the exact absent key	exactly one key, and you know it	~0	P and S both maximally favourable	separate capacity partition

Read the table as a gradient with one anomaly. Everything gets worse with derivation distance except metadata, which sits high on the ladder and is nonetheless the best deal here. That anomaly is the most useful thing in this article, so we take it second.