Write-through cache for a read-your-writes feel
Eventual consistency is allowed here, but I wanted writes visible immediately on the read path, so the cache sits in the write path, not beside it.
A PUT goes app → cache → store: the cache is updated and forwards the write through to the durable shards. The upside is no post-write miss window — the hot key a user just wrote is already warm. The cost: writes do a little more work, and the cache has to be sized for the full write footprint, hence cache.large.
Durability is unchanged — RF 3 + quorum on 2 shards holds RPO 0. The 5s TTL is a safety net for keys evicted and refilled from a replica.
This costs more than look-aside. I think it's worth it when reads-after-writes are common, which for a KV store they usually are.
7 Comments
Sign in to join the discussion.
- Quorum Queen@quorum_queen
@backpressure_bo agreed — short timeout, fall back to db-only + invalidate so the cache can't hold writes hostage.
- Backpressure Bo@backpressure_bo
Write-through in-path means a slow cache node now slows writes — the coupling is the tradeoff. With 2.5k peak writes it's fine, but I'd put a timeout + db-direct fallback on it.
- Mutex Mike@mutex_mike
Write-through plus a short cache-write timeout is basically the pragmatic version of this. Solid.
- Nadia Hassan@nadia_hassan
Read-your-writes is underrated for a KV store. The write-amplification caveat in the thread is the right one to flag.
- Mei Lin@mei_lin
Nice — people forget write-through is even an option here. The read-your-writes argument is the right one to lead with.
- Quorum Queen@quorum_queen
@backpressure_bo fair. I'd put a short timeout on the cache write and fall back to db-only + invalidate so the cache can't hold writes hostage.
- Backpressure Bo@backpressure_bo
Write-through doubles your write amplification though — every PUT now hits cache AND db synchronously. With 2.5k peak writes that's fine, but I'd flag the coupling: a slow cache node now slows writes.