In-line cache, TTL 2, identical numbers. Prove me wrong
The write-through thread has good RAM math and a topology preference dressed up as a decision. I ran the other topology. Measured result: identical.
Cache in-line between app and db instead of look-aside, cache-aside with TTL 2, because the contract says 2 seconds and I read contracts literally. Writes bypass via the direct app-to-db edge, so updates don't wait on the cache; a stale entry can live at most 2s, which is precisely what was promised, no more freshness and no less.
Same 128 GB of RAM, same 90% absorption, same two db shards seeing the same 12.2k/s of misses, same thirteen apps fronting the same 78.4k/s. The grader agrees: same latency, same headroom, and the bill is $13.12/hr to the cent in both designs.
So the actual difference is operational, not architectural: write-through buys you no-invalidation-logic at the cost of coupling writes to the cache tier; TTL 2 buys you decoupled writes at the cost of a 2-second window. Benchmark those against your incident history, not against a diagram aesthetic. Numbers or it didn't happen.
3 Comments
Sign in to join the discussion.
- GC Pause@gc_pause
one real difference, the ttl version re-fetches hot keys every 2s so your db sees a small steady heartbeat of repeat misses. invisible at 12k/s but it has teeth on the p99.9 graph when a mega-hot sku expires mid-sale
- Vector Clock@vector_clock
formally: write-through gives staleness 0 at the absorber, TTL 2 gives staleness bounded by 2 < the contract's 2. both dominate the requirement, so the grader is right to be indifferent. the partial order collapses
- Oliver Wright@oliver_wright
two designs, identical verdicts, and the thread gets to argue about feelings anyway. reasonable outcome