Your cache and DB are out of sync. Again.
A user updates their profile. The cache still serves the old name for the next 10 minutes. Support gets a ticket. You patch it with a cache flush. It happens again next week.
You’re asked to fix write consistency before it becomes a customer-facing incident.
Here’s the setup:
NestJS API → PostgreSQL (source of truth) + Redis (cache)
~600 req/s reads, ~80 req/s writes at peak
Current pattern: write to DB, manually invalidate cache key on success
3 incidents this month — all traced back to stale cache after writes
You need a strategy that survives race conditions, retries, and partial failures
What do you change?
A) Write-through — write to cache and DB together, synchronously. Cache is always warm, always consistent.
B) Write-behind — write to cache first, async flush to DB. Fast writes, eventual persistence.
C) Write-around — skip the cache on writes entirely. Write to DB only. Cache fills on next read miss.
D) Dual-write with an outbox — write to DB + publish an event. A consumer updates the cache from the event log.
All four are used in production. Only one actually survives the failure modes in this setup.
Pick one — A, B, C, or D — and tell me why. I’ll drop the full breakdown in the comments (including the one that looks safest but will burn you at scale).
If your team argues about this at design review, share it with them. The debate is worth having before an incident forces it.
Drop your answer 👇
#30DaysOfSystemDesign #SystemDesign #Caching #SoftwareArchitecture

You can share you thought with this squad 

Backend Developer 

A practical system design scenario where a NestJS API backed by PostgreSQL and Redis is experiencing cache-DB inconsistency causing production incidents. The post presents four caching write strategies — write-through, write-behind, write-around, and dual-write with an outbox pattern — and asks readers to identify which best handles race conditions, retries, and partial failures at ~600 req/s reads and ~80 req/s writes.

26/30 Days System Design Quesitons!

Answer: D — Dual-write with an outbox
The core problem isn’t “which order to write in” — it’s “what happens when one write succeeds and the other fails?”
Why D wins: Every naive dual-write has the same race condition: write to DB, write to cache, crash between the two → stale cache indefinitely. The outbox makes the cache update a consequence of the DB write, not a sibling operation. One atomic DB transaction: record + outbox event. A consumer updates Redis from the event. Also gives you replay — if Redis goes down and comes back, re-process the outbox.
<img src="https://media.daily.dev/image/upload/s--RuRox4Nn--/f_auto/v1780334702/ugc/content_afc7259c-08ef-40e8-94f8-8eaec40e3755?_a=BAMAMiWQ0" alt="ChatGPT Image Jun 1, 2026, 08_21_20 PM.png">

Why A fails (Write-through): Looks safest. Is the most dangerous at scale. Two synchronous I/Os on every write. If Redis is slow, your write API is slow. If Redis is down, do you block the user? You’ve made Redis a hard dependency of your write path.

Also, it would mean a lot to me if you could support my content and stay in touch 🙏
<ul>
<li>YouTube: <a href="https://www.youtube.com/@system-design-lab" target="_blank" rel="noopener nofollow">https://www.youtube.com/@system-design-lab</a></li>
<li>LinkedIn: <a href="https://www.linkedin.com/in/joud-awad/" target="_blank" rel="noopener nofollow">https://www.linkedin.com/in/joud-awad/</a></li>
<li>Medium Blog: <a href="https://joudwawad.medium.com/" target="_blank" rel="noopener nofollow">https://joudwawad.medium.com/</a></li>
<li>Substack: <a href="https://joudawad.substack.com/" target="_blank" rel="noopener nofollow">https://joudawad.substack.com/</a></li>
</ul>

Why B fails (Write-behind): Fast, but: if the async worker crashes before DB flush, that write is gone. Acceptable for analytics counters. Never acceptable for a source of truth.

Why C is a partial fix (Write-around): Solves stale cache by not writing to cache at all. Clean — but read-after-write is broken under replica lag, and high-write workloads tank your cache hit rate.