--- title: 8/30 Days System Design Questions! | daily.dev description: A practical system design scenario involving an e-commerce product catalog running Redis in front of Postgres at 40K RPS. After shipping to production, stale... canonical: https://daily.dev/posts/8-30-days-system-design-questions--v5upagnwh twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 8/30 Days System Design Questions! | daily.dev og:description: A practical system design scenario involving an e-commerce product catalog running Redis in front of Postgres at 40K RPS. After shipping to production, stale... og:url: https://daily.dev/posts/8-30-days-system-design-questions--v5upagnwh og:image: https://api.daily.dev/og/posts/V5UPaGnwH.png og:image:alt: 8/30 Days System Design Questions! og:image:width: 1200 og:image:height: 630 og:locale: 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. # 8/30 Days System Design Questions! **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 296 upvotes · 36 comments ## Summary A practical system design scenario involving an e-commerce product catalog running Redis in front of Postgres at 40K RPS. After shipping to production, stale cache data causes customers to see wrong prices and incorrect stock counts. The post presents four cache invalidation strategies — write-through, write-behind, cache-aside, and read-through — and asks readers to identify which pattern best solves the stale data problem given the specific read/write topology described. ## Content E-commerce product catalog. Redis in front of Postgres. 40K RPS at peak. In staging, cache hit ratio sits at 94%. Response times under 20ms. Everything looks clean. Ship to prod. Within 48 hours, support tickets start rolling in. Customers seeing wrong prices. Old stock counts. Products showing "available" that shipped out three hours ago. Here's the setup: App (Node.js) → Redis (cache) → Postgres (source of truth) Writes come from: admin panel (price updates), inventory service (stock decrements), order service (purchase events). Reads come from: product pages, search results, checkout flow. The cache is leaking stale data in production. Your team is debating the invalidation strategy. What do you ship? A) Write-through — every write hits cache and Postgres in the same transaction. Cache is never stale. B) Write-behind (write-back) — writes land in Redis first, async worker flushes to Postgres in batches. C) Cache-aside (lazy loading) — app writes directly to Postgres, invalidates the cache key, lets the next read repopulate. D) Read-through — Redis sits inline, handles its own misses, pulls from Postgres when needed. All four are patterns senior engineers ship to production. Only one actually matches the shape of this problem. Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments. If your team has had this exact argument at 2am during an incident, share this with them. This one's worth debating. Drop your answer 👇 #30DaysOfSystemDesign #Day8 #SystemDesign #Caching ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 27 upvotes > **✅ Answer: C — Cache-aside** > > > **Why C wins:** > > Multiple write paths (admin panel, inventory service, order service) all hit Postgres independently. Cache-aside fits perfectly: each writer updates Postgres → invalidates the cache key (DEL product:123) → next read misses → fetches fresh data → repopulates Redis. Postgres stays the uncontested source of truth. Redis is just a disposable read accelerator. If Redis dies, the app still works — slower, but correct. This is what Shopify, Etsy, and most AWS reference architectures run in prod. > > , [#postgresql](https://daily.dev/tags/postgresql), [#redis](https://daily.dev/tags/redis) [View this post on daily.dev](https://daily.dev/posts/8-30-days-system-design-questions--v5upagnwh) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/8-30-days-system-design-questions--v5upagnwh","headline":"8/30 Days System Design Questions!","text":"A practical system design scenario involving an e-commerce product catalog running Redis in front of Postgres at 40K RPS. After shipping to production, stale cache data causes customers to see wrong prices and incorrect stock counts. The post presents four cache invalidation strategies — write-through, write-behind, cache-aside, and read-through — and asks readers to identify which pattern best solves the stale data problem given the specific read/write topology described.","url":"https://daily.dev/posts/8-30-days-system-design-questions--v5upagnwh","datePublished":"2026-05-13T16:27:05.730Z","dateModified":"2026-05-13T16:27:29.960Z","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0","description":"Principal Solution Architecture ","worksFor":{"@type":"Organization","name":"Metalab","logo":"https://www.google.com/s2/favicons?domain=metalab.com&sz=128"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":81870}},"image":"https://media.daily.dev/image/upload/s--1ulPUEPW--/f_auto/v1778689632/posts/V5UPaGnwH?_a=BAMAMiWQ0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":296},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":36}],"comment":[{"@type":"Comment","text":"✅ Answer: C — Cache-aside\nWhy C wins:\nMultiple write paths (admin panel, inventory service, order service) all hit Postgres independently. Cache-aside fits perfectly: each writer updates Postgres → invalidates the cache key (DEL product:123) → next read misses → fetches fresh data → repopulates Redis. Postgres stays the uncontested source of truth. Redis is just a disposable read accelerator. If Redis dies, the app still works — slower, but correct. This is what Shopify, Etsy, and most AWS reference architectures run in prod.","datePublished":"2026-05-13T16:27:47.693Z","url":"https://daily.dev/posts/V5UPaGnwH#c-wFkYrwje4","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":27}},{"@type":"Comment","text":"Why A is the trap (Write-through):\n“We write to both atomically” — except there’s no distributed transaction between Redis and Postgres. You write to Postgres, then write to Redis. If the Redis write fails (network blip, timeout), you have consistent Postgres + stale Redis. The exact bug you were trying to fix. Worse, write-through couples every service to Redis — now your inventory service and order service both need Redis credentials. One Redis outage takes down your entire write path. Works great for single-service/single-writer systems. Falls apart with multiple writers.","datePublished":"2026-05-13T16:28:01.173Z","url":"https://daily.dev/posts/V5UPaGnwH#c-IL7CgYR2G","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10}},{"@type":"Comment","text":"Why B is wrong (Write-behind):\nRedis becomes your source of truth. Redis loses data during failovers, OOM kills, AOF lag. “We might lose the last few price updates” is not defensible in a postmortem when real money is involved. Write-behind belongs in metrics pipelines and analytics counters — not e-commerce write paths.","datePublished":"2026-05-13T16:28:05.338Z","url":"https://daily.dev/posts/V5UPaGnwH#c-qymNq0Im2","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5}},{"@type":"Comment","text":"Your explanation doesn’t really hold up.\nIf you’re referring to case A, where write-through can fail because of network issues, timeouts, etc. -> then case C has the exact same problem:\nEach writer updates Postgres → then invalidates the cache key.\nBut what happens if the invalidation step fails?\nThe cache never gets evicted, which means stale data remains in the cache. That’s essentially the same issue as case A, right?\nSo this isn’t really the advantage you’re making it out to be.","datePublished":"2026-05-14T04:47:38.657Z","url":"https://daily.dev/posts/V5UPaGnwH#c-HD21TbAsI","author":{"@type":"Person","name":"Phu Dang","url":"https://daily.dev/phudang2412","image":"https://lh3.googleusercontent.com/a/AAcHTtc7zdWCv55X-Rqd22zBbjqLghdRPXXvIwLaygyX7T5moqg=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"Why D is wrong (Read-through):\nOnly solves the read side. Your writes are still going through 3 different services with nothing telling the cache. Read-through doesn’t fix stale data from multiple writers — you’d still need invalidation on top, which is just cache-aside with extra steps.","datePublished":"2026-05-13T16:28:10.264Z","url":"https://daily.dev/posts/V5UPaGnwH#c-gxOx6op4k","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh","name":"Joud Awad"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Joud Awad","item":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh"},{"@type":"ListItem","position":3,"name":"8/30 Days System Design Questions!"}]} ```