Caching on Brian Faust

A Cache Hit Still Has a Payload

Mon, 15 Jun 2026 00:00:00 +0000

The rules were cached. The expensive graph had already been compiled. A warm request should have been the easy case, yet loading that prepared data was still taking enough work to deserve its own investigation. The cache was working; the representation inside it was the problem.

One attempted fix was to cache a larger, ready-to-use pricing profile and skip reconstruction. That made cache-hit performance worse. Later, compacting rows helped, moving their expansion helped, and then keeping one expensive family expanded helped too. Apparently contradictory results, until you follow where each version made the request do its work.

Compile Published Rules Before the Quote Arrives

Fri, 01 May 2026 00:00:00 +0000

A cache flush shouldn’t make the next quote rebuild a price book that was already published. The shipment is new. The structure of the tariff isn’t. Yet “load the graph, prepare it, cache it” puts both jobs back on the request as soon as the cache disappears.

That boundary changed during development of my private rating engine. First, published rulesets gained a persisted runtime projection. Later, supporting configuration gained a separate persisted bundle. These changes didn’t precompute shipment prices. They gave repeated preparation somewhere to survive other than a volatile cache.

A Cache Hit Is Not a Freshness Guarantee

Tue, 01 Apr 2025 00:00:00 +0000

A catalogue price is cached at revision 1. The database commits revision 2. Three seconds later, Laravel finds the key and returns revision 1 from inside its declared five-second fresh window.

The cache hit is real. So is the stale price.

In the LAR-06 fixture , the cached JSON is well formed and its SHA-256 hash matches its body. Nothing has expired or become corrupt. The failure is semantic: current-price requires the acknowledged source revision, while the cache only knows that a key still contains bytes.

Cache the Deployment, Not the Assumption

Sun, 01 Dec 2024 00:00:00 +0000

Release B serves /inventory and labels its catalogue green. The code is correct. The environment is correct. Yet the application answers /catalogue with blue, while /inventory returns 404.

Nothing corrupted Laravel’s generated files. They contain release A’s configuration and route table because release A created them. The deployment combined those files with release B and produced a system which is consistently wrong.

config:cache and route:cache are often introduced as performance switches. That description misses their more important property: each command turns a set of inputs into a generated artifact. If the artifact is deployed, it must carry the same release identity as the code and environment which produced it.

A Cache Must Distinguish Empty from Unavailable

Mon, 01 Oct 2018 00:00:00 +0000

A cached search returns two pickup locations. One location is deleted locally, but the search keeps returning both.

The tempting repair is a shorter time to live. That trades a known correctness bug for a shorter known correctness bug. The system already knows the cached answer is false; waiting five minutes instead of an hour does not make it less false. A TTL is not invalidation with worse timing.

The opposite failure looks similar. A remote lookup returns nothing during an outage. Replacing the cache with an empty list would remove locations which may still exist.