Scaling Reads hard
Dynamo-style databases (like Cassandra) use 'Sloppy Quorums' and 'Hinted Handoff' to ensure high availability. What is the trade-off for reads?
- A Writes become slower.
- B The database becomes single-threaded.
- C It breaks Strong Consistency guarantees. You might think you wrote to a Quorum, but you actually wrote to a temporary 'Hinted' node because the main node was down. A subsequent Read might miss this data.
- D It requires more disk space.
Answer: C. It breaks Strong Consistency guarantees. You might think you wrote to a Quorum, but you actually wrote to a temporary 'Hinted' node because the main node was down. A subsequent Read might miss this data.
Sloppy Quorums prioritize 'Write Availability' over 'Consistency'. If the designated replicas are down, the system accepts the write on a neighbor. A reader querying the designated replicas won't see it until the handoff completes.
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?