---
title: "26/30 Days System Design Quesitons!"
url: https://daily.dev/posts/26-30-days-system-design-quesitons--woftb93cn
source_url: https://daily.dev/posts/26-30-days-system-design-quesitons--woftb93cn
type: freeform
source: "Backend Developer "
author: "Joud Awad"
published: 2026-06-01T19:47:47.972Z
updated: 2026-06-01T19:48:31.044Z
reading_time: 2
upvotes: 14
comments: 8
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 26/30 Days System Design Quesitons!

**[Backend Developer ](https://daily.dev/sources/amandeep58)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 14 upvotes · 8 comments

## Summary

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.

## Content

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

## Community discussion

Top comments from developers on daily.dev.

**@joudawad** · 3 upvotes

> **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.
>
>
> ![ChatGPT Image Jun 1,...

**@joudawad** · 0 upvotes

> **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.

**@joudawad** · 0 upvotes

> Also, it would mean a lot to me if you could support my content and stay in touch 🙏
>
> - YouTube: [https://www.youtube.com/@system-design-lab](https://www.youtube.com/@system-design-lab)
> - LinkedIn: [https://www.linkedin.com/in/joud-awad/](https://www.linkedin.com/in/joud-awad/)
> - Medium Blog: [https://joudwawad.medium.com/](https://joudwawad.medium.com/)
> - Substack: [https://joudawad.substack.com/](https://joudawad.substack.com/)

**@joudawad** · 0 upvotes

> **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.

**@joudawad** · 0 upvotes

> **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.

---

[View this post on daily.dev](https://daily.dev/posts/26-30-days-system-design-quesitons--woftb93cn)