Production Bloom Filter Monitoring

A deployed Bloom filter degrades silently as load grows past its planned capacity. The system keeps running; the false-positive rate just creeps up. By the time someone notices the cache hit rate cratered, you've been serving expensive lookups for everything for hours.

Monitoring is not optional.

Three cheap metrics

1. load = n_added / expected_n. Easy to track; spikes past 1.0 mean "you sized for the wrong N".
2. fill = popcount(bit_array) / m. The theoretical fill at optimal k and capacity N is exactly 0.5. Fill > 0.5 ⇒ you're past N; fill > 0.7 ⇒ FP rate is already 5-10x target.
3. probe-based actual FP. Periodically query strings you KNOW were never inserted (a separate namespace prefix works); count how often the filter wrongly says MAYBE. Compare against the theoretical curve.

A simple health check

When to rebuild

• Load > planned capacity: schedule a rebuild at a bigger size during low-traffic hours.
• FP rate climbing: rebuild urgently — every false positive is wasted backend work.
• Hash distribution skew (e.g. adversarial inputs): switch to a stronger hash, possibly per-request salted.

Production rebuild patterns

• Double-buffered: keep TWO filters. Inserts go into both; once filter B is "warm", swap reads to B and discard A.
• Versioned: write the filter version into the entries; readers prefer the latest version. Old version is read-only and eventually evicted.
• Scalable Bloom: lets you avoid the rebuild entirely at the cost of slightly more memory and a multi-filter lookup.

The capstone problem in the next lesson ties cache, Bloom, and a basic health check together.