Caching hard
A Bloom Filter is used to prevent Cache Penetration. It reports that a key is 'Present'. You check the cache and DB, but the key does NOT exist. What happened?
- A The system has encountered a 'False Negative' error where the data exists in the persistent store but was incorrectly reported missing by the filter.
- B The Bloom Filter produced a 'False Positive', which is a known probabilistic trade-off where an absent item is reported as being potentially present.
- C The internal bit-array of the filter has reached its maximum capacity limit, causing it to automatically default to a 'Present' signal for all keys.
- D The cache node has experienced a localized hardware bit-rot event that corrupted the specific memory segment dedicated to the Bloom Filter data.
Answer: B. The Bloom Filter produced a 'False Positive', which is a known probabilistic trade-off where an absent item is reported as being potentially present.
This result (answering 'Present' when the item is actually absent) is a **False Positive**. Bloom Filters trade space efficiency for accuracy. They never produce False Negatives (if it says 'Absent', it is definitely absent), but they have a small error rate for presence, which the application must handle (usually by checking the source of truth).
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- What is the primary architectural goal of introducing a cache into a system?
- Most caching systems rely on the principle of 'Temporal Locality', which states:
- Your cache uses an LRU (Least Recently Used) eviction policy. When the cache is full, which item is removed?