--- title: 57/60 Days System Design Questions | daily.dev description: A system design challenge presents a high-traffic scenario with 50k writes/sec and 500k reads/sec on a Postgres setup with one primary and two async replicas.... canonical: https://daily.dev/posts/57-60-days-system-design-questions-niduayotf twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 57/60 Days System Design Questions | daily.dev og:description: A system design challenge presents a high-traffic scenario with 50k writes/sec and 500k reads/sec on a Postgres setup with one primary and two async replicas.... og:url: https://daily.dev/posts/57-60-days-system-design-questions-niduayotf og:image: https://api.daily.dev/og/posts/nIduaYOTF.png og:image:alt: 57/60 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. # 57/60 Days System Design Questions **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 1 min read · 167 upvotes · 22 comments ## Summary A system design challenge presents a high-traffic scenario with 50k writes/sec and 500k reads/sec on a Postgres setup with one primary and two async replicas. The problem: a payment confirmation flow reads stale data from a replica due to 80–300ms replication lag. Four options are presented to achieve read-after-write consistency without sacrificing write throughput: synchronous replication, semi-sync replication, routing payment reads to the primary, or adding a sleep delay after writes. ## Content Your write traffic just hit 50k writes/sec. Reads are 10x that. You split your Postgres into one primary + two replicas. Reads go to replicas. Now you're shipping a payment confirmation flow — and a replica returned stale data 200ms after a write. The user saw "payment pending" when it already succeeded. Here's the setup: → Primary handles all writes → Two read replicas, async replication → Payment confirmation reads from a replica → Replication lag: 80–300ms under load You need reads-after-write consistency on payment flows without tanking write throughput. What do you do? A) Switch to synchronous replication — primary waits for at least one replica to confirm before ack'ing the write. B) Use semi-sync replication — primary waits for exactly one replica to write to its relay log, but not flush to disk. C) Route payment confirmation reads back to the primary, keep everything else on replicas. D) Add a short sleep (500ms) after every payment write before reading — wait out the lag. Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments. Drop your answer 👇 _#30DaysOfSystemDesign #SystemDesign #Databases #SoftwareArchitecture_ ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 24 upvotes > **Why A is tempting but the wrong trade (synchronous replication):** > > > Postgres synchronous_commit = on — primary waits for a replica to confirm before ack'ing the write. Zero lag. Reads always consistent. > > > The cost: every write now takes primary_write_time + network roundtrip to replica. 1–5ms normally. Under load with a flaky replica? Your write latency is hostage to your slowest replica. > > > If that sync replica goes down → you either halt writes or fall back to async and break your guarantee. That choice gets made at 3am under pressure. > > > Sync replication is a serious architectural... **@joudawad** · 23 upvotes > **Why C wins (primary reads for critical paths):** > > > Payment confirmations are a tiny slice of your read traffic. You're not routing ALL reads to primary — just the reads where stale data causes visible user harm. > > > This pattern is called **read-your-writes consistency**. Stripe, Shopify, every serious fintech does this. You add a flag or middleware: "if this is a consistency-sensitive flow, read from primary." Everything else keeps hitting replicas. > > > Primary read traffic increases slightly — but a "just confirmed payment" flow is maybe 0.1% of your reads. Negligible. No topology change, no... **@joudawad** · 21 upvotes > **Why B is the sneaky wrong answer (semi-sync replication):** > > > Semi-sync (rpl_semi_sync in MySQL) — primary waits for one replica to write to its relay log. Sounds like a middle ground. It's not. > > > The replica acknowledged receipt of the bytes — not that the data is applied and readable. The relay log is the _incoming queue_, not the applied state. You can still read stale data immediately after a write. > > > Semi-sync protects you from **data loss on primary failure**. It does NOT protect you from replication lag on reads. Different problem entirely. > > > Senior engineers conflate "replica has... **@joudawad** · 19 upvotes > **Why D will destroy you at scale (sleep-based lag compensation):** > > > Sounds pragmatic. Works for about 2 weeks. > > > Replication lag isn't a fixed constant. It's 50ms now, 300ms during a write spike, 2s during a vacuum. Hardcode a sleep and you've built a system that's either too slow (sleep > lag) or still broken (lag > sleep). > > > Every payment confirmation path is now artificially 500ms slower. And when the sleep isn't enough during a spike — you're back to the original bug, with worse latency. > > > Sleep-based consistency is always a smell. **@kibongo** · 9 upvotes > C works. But one improvement would be to combine primary reads with a short-lived cache of the write result, so we avoid duplicate primary hits for immediate confirmation flows. --- Tags: [#career](https://daily.dev/tags/career), [#backend](https://daily.dev/tags/backend), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/57-60-days-system-design-questions-niduayotf) ```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/57-60-days-system-design-questions-niduayotf","headline":"57/60 Days System Design Questions","text":"A system design challenge presents a high-traffic scenario with 50k writes/sec and 500k reads/sec on a Postgres setup with one primary and two async replicas. The problem: a payment confirmation flow reads stale data from a replica due to 80–300ms replication lag. Four options are presented to achieve read-after-write consistency without sacrificing write throughput: synchronous replication, semi-sync replication, routing payment reads to the primary, or adding a sleep delay after writes.","url":"https://daily.dev/posts/57-60-days-system-design-questions-niduayotf","datePublished":"2026-07-02T14:23:34.957Z","dateModified":"2026-07-03T04:17:38.342Z","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--eAsatTsZ--/f_auto/v1783002219/posts/nIduaYOTF?_a=BAMAMicg0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":167},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":22}],"comment":[{"@type":"Comment","text":"Why A is tempting but the wrong trade (synchronous replication):\nPostgres synchronous_commit = on — primary waits for a replica to confirm before ack’ing the write. Zero lag. Reads always consistent.\nThe cost: every write now takes primary_write_time + network roundtrip to replica. 1–5ms normally. Under load with a flaky replica? Your write latency is hostage to your slowest replica.\nIf that sync replica goes down → you either halt writes or fall back to async and break your guarantee. That choice gets made at 3am under pressure.\nSync replication is a serious architectural commitment for the whole DB. Routing payment reads to primary solves the same problem, surgically.","datePublished":"2026-07-02T14:23:56.087Z","url":"https://daily.dev/posts/nIduaYOTF#c-sDyNEZYHs","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":24}},{"@type":"Comment","text":"Why C wins (primary reads for critical paths):\nPayment confirmations are a tiny slice of your read traffic. You’re not routing ALL reads to primary — just the reads where stale data causes visible user harm.\nThis pattern is called read-your-writes consistency. Stripe, Shopify, every serious fintech does this. You add a flag or middleware: “if this is a consistency-sensitive flow, read from primary.” Everything else keeps hitting replicas.\nPrimary read traffic increases slightly — but a “just confirmed payment” flow is maybe 0.1% of your reads. Negligible. No topology change, no new failure modes, surgical precision.","datePublished":"2026-07-02T14:25:53.956Z","url":"https://daily.dev/posts/nIduaYOTF#c-ThSfQNety","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":23}},{"@type":"Comment","text":"Why B is the sneaky wrong answer (semi-sync replication):\nSemi-sync (rpl_semi_sync in MySQL) — primary waits for one replica to write to its relay log. Sounds like a middle ground. It’s not.\nThe replica acknowledged receipt of the bytes — not that the data is applied and readable. The relay log is the incoming queue, not the applied state. You can still read stale data immediately after a write.\nSemi-sync protects you from data loss on primary failure. It does NOT protect you from replication lag on reads. Different problem entirely.\nSenior engineers conflate “replica has the data” with “replica has applied the data.” They’re not the same thing.","datePublished":"2026-07-02T14:24:01.082Z","url":"https://daily.dev/posts/nIduaYOTF#c-TcwzBDp0T","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":21}},{"@type":"Comment","text":"Why D will destroy you at scale (sleep-based lag compensation):\nSounds pragmatic. Works for about 2 weeks.\nReplication lag isn’t a fixed constant. It’s 50ms now, 300ms during a write spike, 2s during a vacuum. Hardcode a sleep and you’ve built a system that’s either too slow (sleep > lag) or still broken (lag > sleep).\nEvery payment confirmation path is now artificially 500ms slower. And when the sleep isn’t enough during a spike — you’re back to the original bug, with worse latency.\nSleep-based consistency is always a smell.","datePublished":"2026-07-02T14:24:08.126Z","url":"https://daily.dev/posts/nIduaYOTF#c-LOcTL7poN","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":19}},{"@type":"Comment","text":"C works. But one improvement would be to combine primary reads with a short-lived cache of the write result, so we avoid duplicate primary hits for immediate confirmation flows.","datePublished":"2026-07-02T17:43:55.589Z","url":"https://daily.dev/posts/nIduaYOTF#c-nY0fxi5Tf","author":{"@type":"Person","name":"KIBONGO Simon Peter","url":"https://daily.dev/kibongo","image":"https://lh3.googleusercontent.com/a/ACg8ocLXNKVhVIvovYerRL1paJ7Y9hhXP4lDsb9Or0VvdeeVGTfL9sx-KQ=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":9}}],"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":"57/60 Days System Design Questions"}]} ```