Loading today’s stories
Build1 distinct publisher3 min readUpdated
A cache-aside demo turned 10,000 database reads into one. The arithmetic that explains the gap also caps what the next rung of hit rate can buy.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Divide the two measured totals and the mechanism falls out. If 0.6 ms is 3,084 times faster than the uncached run, that run was about 1.85 s, or roughly 185 microseconds per read [3][1]. One read still paid that price [5]. So of the 0.6 ms the cached run took, about 0.185 ms was the single surviving database call: close to a third of the wall clock spent on 0.01 percent of the traffic [2]. The other 9,999 reads split the remaining 0.415 ms, around 42 nanoseconds each [3].
That is also where the 100x prediction went wrong, and not in the direction the headline number suggests. Counted in misses, one miss out of 10,000 reads should be a 10,000x improvement. Measured was 3,084x, about 31 percent of that [4]. The shortfall is not the database. It is the 9,999 map lookups, which account for 69 percent of what was left [3]. The author records the prediction as off by a factor of 30 [4].
The hit-rate ladder is the same arithmetic run in reverse. At 90 percent of 10,000 reads, 1,000 misses remain; at 99 percent, 100; the measured difference between those two rows was 10x [8]. By the same count, 99.9 percent leaves 10 misses and buys another 10x [5], and each rung after that closes on the floor the 3,084x run already sat on, where the map lookups dominate and the database is barely present [3]. On a cache across the network the floor is higher, since Redis charges a toll on every hit rather than only on misses [6].
Two of these numbers deserve different levels of trust. The 0.6 ms came off a clock, but the four hit rates were forced onto the same 10,000 reads, so the ratio is simulated and only the timing is real [7]. All of it came off one machine, and the author says the constants will move with your database, driver and network [13]. Miss counts, though, are counted rather than timed, which is why the count survives a change of hardware when the microseconds do not.
The staleness run is the same counting done in the time domain. A value changing 10 times a second changes every 100 ms, so a 300 ms TTL spans three of those intervals [6] and an answer can be two changes behind before anything asks for it again. In one second the cache served 83 reads and 71 were wrong, from a cache the author describes as having nothing broken [10]; 12 answers were current [7]. His rule for which data can afford that: cache the profile photo, never the account balance [11].
Memory behaves the same way. Sixty thousand writes into a map with no limit kept all 60,000 entries and 70 MB, because the map still holds every reference; an access-ordered bound of 1,000 gave 8 MB for the identical writes [12], about 8.75 times less [8]. In each case the quantity that predicted the outcome was what remained, not what was served.
Ranked by verification strength, evidence, and original report placement.
The author ran the same query 10,000 times against a real database, costing almost 2 seconds of database work for an answer that never changed.
Before adding a cache, the author wrote down a prediction that a cache should make the workload about 100 times faster.
The same 10,000 reads through an in-process cache-aside map took 0.6 milliseconds and one database call, which the author reports as 3,084x faster.
Of the 10,000 cached reads, 9,999 paid only a map lookup measured in nanoseconds and one paid the real query price; the cache did not make the query faster, it made it rare.
The author forced four hit rates (0, 50, 90 and 99 percent) onto the same 10,000 reads; he states the ratio is simulated and the clock is not.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Internally consistent but single-machine and unreproducible
Every number comes from one author's demo on one machine, published without a harness, database, driver or hardware disclosure, and with no second source in the cluster. What raises the score above the floor is unusual self-limiting: the author states the hit-rate ratios are forced while the clock is real, scopes the constants to his machine, and reports figures that check out arithmetically against each other (implied 1.85 s baseline, ~42 ns per hit, 8.75x heap ratio). What holds it down is that the headline absolutes rest on an in-process ConcurrentHashMap with a single key, the most favourable possible configuration, and nothing was independently reproduced.
No adoption signal in supplied sources
The cluster contains a tutorial demo only. There is no deployment, production usage, user count, vendor uptake, pricing or licensing evidence for the pattern or for any product, and the passing remarks that browsers, CDNs and databases cache are rhetorical rather than measured. Adoption is therefore not assessable from the supplied material.
Mildly overstated headline, honest body
The directional argument is sound and arguably understated in importance: counting misses rather than hits is real arithmetic, and the 90-to-99 percent 10x step follows from miss counts. The overstatement is in the absolutes carried by the framing. A 3,084x figure comes from repeating one query against an in-process map, a best case no production workload reproduces, and the assertion that a networked cache such as Redis leaves the pattern unchanged is asserted with no measurement even though per-hit network latency compresses exactly that ratio. Explicit caveats about simulated ratios and machine-specific constants keep the gap small rather than large.
Disclosed content-series promotion, no commercial stake
The piece is an episode of the author's own developer-education series: it embeds a video at the top, references an earlier episode, teases the next instalment on invalidation, and closes with an engagement question about production hit rates. That creates an incentive toward memorable, headline-sized numbers such as 3,084x and the 10x-not-9-percent title. There is no vendor, sponsor, product or funding relationship visible in the supplied source, and no commercial technology is being sold, so the distortion pressure is audience-building rather than financial.
Confident on the ratio logic, not on the constants
Confidence is moderate and asymmetric. The miss-count arithmetic and the memory-bound conclusion are verifiable from the article's own figures and would hold on any environment, so those parts of the assessment are firm. The absolute timings, the 3,084x figure and the staleness percentages depend entirely on one undisclosed single-machine setup with no corroborating source in the cluster, and adoption cannot be scored at all, which caps overall confidence in the middle of the range.
Follow any of these and your For You feed starts watching them — no settings page required.
build
Three services you can delete: queue, cache and search in one Postgres1 distinct publisher
build
The /userinfo fallback that quietly made Auth0 a hard dependency on every request1 distinct publisher
build
Shared memory in Java: the mmap is the easy half, the descriptor handoff is the work1 distinct publisher
build
The proxy in your call path decides whether @Transactional does anything at all1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026