Code10x
Caching fundamentalshard5-8 years

Under write latency pressure, a team proposes switching a Redis-backed cache from write-through to write-behind: acknowledge the write immediately, buffer it, and flush to the database on a schedule. What exactly is being traded away, and is it a bug to fix or a tradeoff to make deliberately?

Write-through writes the database synchronously before acknowledging, so a caller only ever gets a success response once the write is actually durable — if it fails, the caller finds out. Write-behind acknowledges the write immediately and buffers it, flushing to the database later in batches; between the acknowledgement and the flush, the only copy of that write anywhere is in the cache tier's memory, and if that process crashes, gets evicted, or its buffer is lost before the flush, the write is gone — silently, because the caller was already told it succeeded and nothing records that it didn't survive. That gap isn't a bug to patch; it's the entire reason write-behind is faster and able to batch writes at all, so the real engineering question is how big that window is and what's actually acceptable to lose during it, not how to eliminate it (eliminating it just turns write-behind back into write-through with extra steps).

The lesson behind it →
PreviousThree service instances coordinate through a Redis lock (`SET lock:invoice-1041 <owner> NX PX 1000`) before sending an invoice, so only one should send it. Worker A acquires the lock, then a GC pause holds it inside its critical section for 1.5 seconds — longer than the lock's 1-second expiry. Walk through what actually happens, and what a plain `DEL` on release makes worse.Next A team is deciding whether to use Redis's Redlock algorithm (acquiring a lock across a majority of independent Redis nodes) for a correctness-critical operation — one where two holders acting at once would corrupt data. What does Redlock's quorum actually buy over a single Redis instance, and where does Martin Kleppmann's critique of it actually land?
More on Caching fundamentals
A team adds a Redis cache in front of a product lookup and is surprised the win is only partly about speed — what does a cache actually buy beyond raw latency, and why should every cached entry get a TTL even when the application also deletes the entry on every write?A Redis cache configured with `maxmemory-policy allkeys-lru` holds a tenth of the working set under realistic skewed traffic. A teammate suggests switching to `allkeys-lfu` to improve the hit ratio. Would that help, and what's actually being tuned when the eviction policy changes?A scraper walking through sequential product ids, many of which don't exist, is sending every one of those requests straight through the cache to the database, even though the service already uses cache-aside. Why doesn't cache-aside help here, and what closes the gap?