Scaling Reads hard
You use a Bloom Filter to optimize reads by avoiding disk lookups for non-existent keys. As the number of items in the DB grows beyond the Bloom Filter's capacity, what happens?
- A The False Negative rate increases (System says 'Not Exists' when it does exist).
- B The False Positive rate increases (System says 'Might Exist' when it doesn't), causing unnecessary disk lookups and degrading read performance.
- C The database crashes.
- D The Bloom Filter automatically resizes.
Answer: B. The False Positive rate increases (System says 'Might Exist' when it doesn't), causing unnecessary disk lookups and degrading read performance.
Bloom Filters cannot resize dynamically (usually). If they overfill, the bit array becomes mostly '1's. The filter starts saying 'Yes, maybe' to almost everything, rendering it useless as an optimization.
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?