Scaling Reads hard
In a sharded database, what is the 'Scatter-Gather' problem associated with Global Secondary Indexes?
- A Reads are fast, writes are slow.
- B If you query by a field that is NOT the Shard Key, the query coordinator must send the request to *every single shard* and merge the results, causing high latency and CPU usage.
- C Indexes cannot be created on sharded tables.
- D Data becomes corrupted.
Answer: B. If you query by a field that is NOT the Shard Key, the query coordinator must send the request to *every single shard* and merge the results, causing high latency and CPU usage.
If you shard by `UserID` but search by `Email`, the system doesn't know which shard holds `alice@example.com`. It has to ask everyone. This scales linearly with cluster size (badly).
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a caching system, what is a 'Cache Miss'?
- Why is `SELECT * FROM Users` generally discouraged in high-performance applications compared to `SELECT name, email FROM Users`?
- You have users all over the world downloading large images from your server in New York. Users in Australia complain it is slow. What solves this?
- What is the main downside of reading from a Read Replica instead of the Primary database?
- You have maximized the RAM on your single database server, but it's still too slow. You decide to add 10 more servers to share the load. What is this called?
- You have 5 Read Replicas. How does the application know which one to ask for data?