Exercise 3: Why Read Replicas and Sharding Solve Different Problems — Possible Solution ==================================================================== WHAT READ REPLICAS ACTUALLY FIX, PER THIS CHAPTER'S OWN FINDING ------------------------------ This chapter verified read replicas reduce PER-SERVER READ LOAD - 30 reads that would have all hit one primary got spread to 10 per server across 3 replicas. Crucially, this chapter also verified each individual read's own speed was UNCHANGED - a replica read costs exactly what a primary read costs; replicas just mean fewer total reads land on any one machine. Read replicas fix "too many read REQUESTS for one server to handle," not "any individual operation is slow." WHAT SHARDING ACTUALLY FIXES, PER THIS CHAPTER'S OWN FINDING ------------------------------ This chapter verified sharding splits the DATA ITSELF across multiple databases, so each shard only has to store and search a fraction of the total dataset - the direct database-level version of Chapter 1's own linear-scan finding, where a smaller list to search means less work per search. Sharding fixes "the dataset itself is too big for one database to search or store efficiently," a genuinely different problem from "too many requests are arriving." WOULD EITHER ONE HAVE HELPED CHAPTER 1'S OWN O(n) BOTTLENECK? ------------------------------ Read replicas: NO. Chapter 1's own bottleneck was a linear scan through order IDs - copying that identical, unmodified O(n) scan onto more replica servers just means MORE servers each independently performing the same slow O(n) work on the SAME full-size list. Nothing about replication makes any single scan faster or shorter. Sharding: PARTIALLY, and only with real added complexity. If the order list were split across shards by, say, order_id, a duplicate-check for a specific order_id could be routed to just the ONE shard that order_id belongs to - genuinely searching a smaller (1/N-sized) list, directly addressing the O(n) cost per this chapter's own cross-shard-vs-single- shard finding. But this only works because a duplicate-ID check can be routed to exactly one shard by definition (the same ID always hashes the same way) - it would NOT help a query that needs to check uniqueness ACROSS all shards at once, which reverts to this chapter's own verified N-times-the-shard-touches cost. WHY THIS WORKS AS AN ANSWER ------------------------------ Each technique's own fix is stated precisely in terms of this chapter's own verified numbers (per-server load vs. per-shard data size) rather than generically, and the Chapter 1 bottleneck is evaluated honestly against both - correctly ruling out replicas entirely and giving sharding a genuinely qualified "partially," rather than claiming either technique is a universal fix.