--- title: "31/60 Days System Design Questions!" url: https://daily.dev/posts/31-60-days-system-design-questions--ojhugu6au source_url: https://daily.dev/posts/31-60-days-system-design-questions--ojhugu6au type: freeform source: "Joud Awad" author: "Joud Awad" published: 2026-06-06T17:34:14.990Z updated: 2026-06-06T17:35:06.729Z reading_time: 2 upvotes: 42 comments: 15 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. # 31/60 Days System Design Questions! **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 42 upvotes · 15 comments ## Summary A system design challenge presents a real-world scenario: an e-commerce platform with 2M daily active users experiencing 380ms latency for European users needs to get under 80ms before Black Friday, with no time for a full database rewrite. Four architectural approaches are presented for debate: Active-Active multi-region with distributed DB, Active-Passive with read replicas, CDN+Edge caching only, and Active-Active with eventual consistency. Readers are asked to pick the best solution given the constraints and explain their reasoning. ## Content Your e-commerce platform just crossed 2M daily active users. 70% are in the US, 30% in Europe. Latency complaints are piling up from European users — 380ms average round-trip to your US-East region. Support tickets are up 40%. Black Friday is in 6 weeks. Your infrastructure: single AWS us-east-1 region, RDS PostgreSQL (primary), Redis cache, 12 microservices behind an API Gateway. You need to get European latency under 80ms. The engineering team is debating four approaches. Here's your constraint: you cannot afford a full database rewrite, and you need this shipped before Black Friday. **A)** Active-Active multi-region — deploy the full stack in eu-west-1, use a distributed database (CockroachDB or Aurora Global), route users to the nearest region. Writes go to both regions simultaneously. **B)** Active-Passive with read replicas — keep us-east-1 as primary, spin up eu-west-1 as a hot standby with read replicas. European reads go local, writes still go to US. Failover in minutes if US goes down. **C)** CDN + Edge caching — keep the single region, push static assets and cacheable API responses to CloudFront edge nodes in Europe. No database changes. **D)** Active-Active with eventual consistency — deploy full stack in both regions, allow each region to own its writes, sync asynchronously. Accept that a European user might see a US write 200ms late. Three of these are real patterns production teams use. Only one actually solves the problem you have — under your constraints, before Black Friday. Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments. If your team has been in this exact debate, share this with them. The tradeoffs are what matter. Drop your answer 👇 _#30DaysOfSystemDesign #SystemDesign #DistributedSystems #SoftwareArchitecture_ ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 3 upvotes > **Why B wins:** > > The constraint is the answer. You can't rewrite the database, and you have 6 weeks. > > > European users are complaining about _read_ latency — browsing products, checking order status, loading their profile. Those are reads. An RDS read replica in eu-west-1 costs you 1–2 days of infra work and immediately moves European reads to ~15ms instead of 380ms. Writes still go to us-east-1 (acceptable — users tolerate slightly higher write latency for checkout). Replication lag is typically under 100ms. > > > Active-passive also gives you a real failover story: US goes down → promote EU... **@joudawad** · 3 upvotes > **The architecture lesson:** > > > Multi-region is a spectrum, not a single decision: > > > ``` > | Pattern | Complexity | What it solves > > | ----------------------------- | ------------- | -------------------------------- | > > | Read replicas | Low | Read latency in other regions > > | Active-passive | Medium | Read latency + failover story > > | Active-active (consistent) | Very high | Write latency + fault isolation > > | Active-active (eventual) | Highest | Max scale, needs conflict resolution > ``` > > > Most teams move left → right over _years_. The mistake is jumping to the right side before you've mastered the... **@joudawad** · 2 upvotes > **Why D is dangerous (Active-Active + eventual consistency):** > > Most honest version of multi-region — and the most dangerous to deploy without prep. Eventual consistency across regions means a European user places an order and your US region sees a different inventory count for 200ms. For limited stock = oversell. For checkout = duplicate charges. Conflict resolution is a product problem disguised as an infra problem. **@joudawad** · 1 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** · 1 upvotes > **Why A is the trap (Active-Active + distributed DB):** > > This is the "correct at scale" answer that kills teams before Black Friday. Migrating from RDS PostgreSQL to CockroachDB or Aurora Global under a 6-week deadline is a multi-quarter project — distributed transactions, global clock skew, new failure modes to test. Right architecture for the long term. Wrong answer for the problem as stated. --- [View this post on daily.dev](https://daily.dev/posts/31-60-days-system-design-questions--ojhugu6au)