Putting It All Together

You've built every variant in this course:

The capstone: cache + Bloom together

The single most common real-world pattern is (cache lookup) gated by (Bloom pre-filter). The Bloom guards an expensive operation; the cache makes successful lookups fast. The capstone combines them:

• PUT_CACHE inserts into BOTH the cache AND the Bloom.
• GET:
  • Bloom says NO → BLOOM_MISS. Skip the cache lookup entirely. This is where Bloom earns its memory.
  • Bloom says MAYBE and key in cache → HIT <value>.
  • Bloom says MAYBE and key NOT in cache → MISS_BLOOM_FP. False positive — Bloom said MAYBE but the cache doesn't have it.
• INVALIDATE removes from the cache. The Bloom cannot remove (basic Bloom limitation). Subsequent GETs of an invalidated key will trip MAYBE in Bloom and then MISS_BLOOM_FP in the cache. This is the Bloom's natural failure mode — pay it back with a rebuild every once in a while.

What you can do now

• Compute Bloom sizing for any target FP rate and item count.
• Choose between Basic, Counting, Cuckoo, and Scalable for the situation.
• Use Bloom unions to merge filters across shards.
• Monitor a deployed Bloom and rebuild before degradation hits production.
• Decide between a Bloom (membership) and a HyperLogLog (cardinality) for different problems.

Next steps: implement these against MurmurHash3 or xxHash, packed bit arrays, and try integrating with a real cache layer (Redis, Memcached, or your own LRU). Production-ready Bloom is ~150 lines of code and saves order-of-magnitude memory.