Your orders service is a Postgres monolith doing 8K writes/min and 40K reads/min.
Same tables. Same schema. Everything’s grinding.
The write side needs a normalized schema — orders, line_items, payments, shipments, addresses. Clean FKs, ACID, no duplicated data. The read side wants the opposite — the dashboard joins 7 tables to render one order card, and the reporting queries are lighting up the CPU at 85% every morning at 9am.
You’ve already tuned indexes. You’ve already added caching. The fundamental problem isn’t hardware — the read model and the write model want different shapes of the same data, and you’ve been pretending they’re the same thing for two years.
Here’s the decision on the table:
A) Full CQRS — separate read/write models, project writes into a denormalized read store (ElasticSearch / a flat Postgres read DB), eventual consistency between them.
B) Add read replicas — point dashboards + reports at the replica, keep writes on the primary.
C) Keep one DB, one model — denormalize the write schema itself (flatten line_items into orders, duplicate customer data) so reads stop joining.
D) Keep the schema, add GraphQL + DataLoader — batch the N+1 reads at the query layer, leave the DB alone.
All four are real patterns you’ll see in production. Three of them dodge the actual problem — and one of them is the senior engineer trap that looks correct for about 6 months until it doesn’t.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
If your team has argued about this exact tradeoff at 11pm before a release, share it with them. The debate sharpens the pattern.
Drop your answer 👇
#30DaysOfSystemDesign #Day9 #SystemDesign #SoftwareArchitecture

You can share you thought with this squad 

Backend Developer 

A system design challenge presents a Postgres monolith handling 8K writes/min and 40K reads/min where read and write models require fundamentally different data shapes. Four architectural options are evaluated: full CQRS with separate read/write stores, read replicas, denormalizing the write schema, or adding GraphQL with DataLoader. Readers are asked to pick the best approach and justify their reasoning, with the author hinting that one option is a senior engineer trap that works short-term but fails later.

9/30 Days System Design Question

✅ Answer: A — Full CQRS
Why A wins:
The pain isn’t “reads are slow” — it’s that the write side wants a normalized schema and the read side wants a denormalized one, and you’re forcing them to share. No amount of hardware fixes a schema shape mismatch. Write side stays clean: orders, line_items, payments, all normalized, ACID, FK-enforced. Read side is a projection: a flat order_view table (or Elasticsearch index) where every order card renders from one row, zero joins. Projector keeps them in sync (outbox → Kafka → read-model updater, or CDC). You eat eventual consistency — the dashboard might lag by a few hundred ms. For 95% of reads (dashboards, reports, search), that’s invisible. For the 5% that needs strong consistency (user’s own order confirmation), read from the write side directly.
<img src="https://media.daily.dev/image/upload/s--DQTaTUtT--/f_auto/v1778834422/ugc/content_72f8e9b1-27cd-4e96-b14c-961dcd8ab039?_a=BAMAMiWQ0" alt="image.png">

Why B is the trap (Read replicas):
B fixes read load. Not read shape. The 7-table join is still a 7-table join — it just runs on different hardware. You’ve moved the CPU bill, not removed it. Latency drops for 6 months while traffic grows, then you’re back where you started with 3 replicas all running the same expensive joins. B is right when the joins are structurally fine but the primary is overwhelmed. Wrong when the joins themselves are the problem.

Why C is wrong (Denormalize the write model):
Every line-item change now rewrites the order row. Every address update cascades through every order ever placed. Write amplification compounds at 8K writes/min. Schema ossifies — adding a field to line_items means migrating millions of denormalized rows. Classic “avoid the architecture conversation” move. Buys a quarter, mortgages two.

Why D is wrong (GraphQL + DataLoader):
DataLoader batches API calls, not joins. The 7-table join happens in the database, not in the application. 3 months of GraphQL migration later, reads are exactly as slow as before. Right answer when clients are the problem. Wrong answer when the DB schema is.

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>