Introduction

A Bloom filter is a space-efficient probabilistic data structure that answers one question: “has this element been seen before?” It uses a tiny bit array and K hash functions—when you add an element, you set K bits; when you check an element, you verify all K bits are set. If any bit is 0, the element is definitely new. If all bits are 1, the element is probably in the set (but could be a false positive). The tradeoff is guaranteed no false negatives with an acceptable false positive rate and significant space savings—making Bloom filters useful in distributed systems.

The math is clean. For n elements and m bits, the optimal number of hash functions is k = (m/n) × ln(2), and the resulting false positive rate is approximately (1 - e^(-kn/m))^k. With a 1% false positive rate, you need about 9.6 bits per element regardless of n. This means storing one million elements requires roughly 1.2 MB instead of the tens of megabytes a hash set would need. The tradeoff is irreversible: once an element is added, you cannot remove it from a standard Bloom filter without risking false negatives on other elements.

Bloom filters show up throughout production systems. Cassandra and HBase use them to skip SSTables that can’t contain a key. Medium and similar platforms use them to avoid recommending articles you’ve already read. Bitcoin uses them in SPV clients to efficiently check transaction existence without downloading the entire blockchain. This guide covers the core mechanics, how to size a Bloom filter correctly for your use case, and advanced variants like Cuckoo filters (which support deletions) and counting Bloom filters (which use more memory but enable removals). A Bloom filter uses a bit array of size M and K hash functions. To add an element, hash it K times and set the corresponding bits to 1. To check if an element exists, hash it K times and check if all corresponding bits are 1.

graph TD
    subgraph BitArray["Bit Array (m=12 bits)"]
        B0["0"]
        B1["1"]
        B2["0"]
        B3["1"]
        B4["0"]
        B5["1"]
        B6["0"]
        B7["0"]
        B8["1"]
        B9["0"]
        B10["1"]
        B11["0"]
    end

graph TD
    subgraph Add["Add Element X"]
        H1["hash1(X) = 2"] --> B2
        H2["hash2(X) = 5"] --> B5
        H3["hash3(X) = 8"] --> B8
    end

    subgraph Check["Check Element Y"]
        H4["hash1(Y) = 2"] --> B2
        H5["hash2(Y) = 4"]
        H6["hash3(Y) = 9"]
    end

If any bit is 0, the element is definitely not in the set. If all bits are 1, the element might be in the set (or it could be a false positive).

Implementation

import math
import hashlib

class BloomFilter:
    def __init__(self, expected_elements: int, false_positive_rate: float):
        self.size = self._calculate_size(expected_elements, false_positive_rate)
        self.hash_count = self._calculate_hash_count(self.size, expected_elements)
        self.bit_array = [0] * self.size

    def _calculate_size(self, n: int, p: float) -> int:
        m = -(n * math.log(p)) / (math.log(2) ** 2)
        return int(math.ceil(m))

    def _calculate_hash_count(self, m: int, n: int) -> int:
        k = (m / n) * math.log(2)
        return int(math.ceil(k))

    def _get_hash_positions(self, element: bytes) -> list[int]:
        positions = []
        for i in range(self.hash_count):
            hash_input = element + str(i).encode()
            hash_value = int.from_bytes(
                hashlib.sha256(hash_input).digest()[:8],
                byteorder='big'
            )
            positions.append(hash_value % self.size)
        return positions

    def add(self, element: bytes):
        for pos in self._get_hash_positions(element):
            self.bit_array[pos] = 1

    def might_contain(self, element: bytes) -> bool:
        return all(self.bit_array[pos] == 1 for pos in self._get_hash_positions(element))

    def clear(self):
        self.bit_array = [0] * self.size

Calculating False Positive Probability

The false positive rate depends on the bit array size, the number of hash functions, and how many elements have been inserted:

def false_positive_rate(size: int, hash_count: int, elements: int) -> float:
    m = size
    k = hash_count
    n = elements

    probability_one_bit = (1 - 1/m) ** (k * n)
    return (1 - probability_one_bit) ** k

FPR Calculator Formula

When designing a Bloom filter, you need to calculate the optimal bit array size (m) and number of hash functions (k) given your expected number of elements (n) and desired false positive rate (p).

The optimal bit array size:

m = - (n * ln(p)) / (ln(2)^2)

The optimal number of hash functions:

k = (m / n) * ln(2)

Verification - the resulting false positive rate:

p = (1 - e^(-k*n/m))^k

import math

def calculate_bloom_filter_params(n: int, p: float) -> dict:
    """
    Calculate optimal Bloom filter parameters.

    Args:
        n: Expected number of elements to be inserted
        p: Desired false positive rate (e.g., 0.01 for 1%)

    Returns:
        Dictionary with optimal m (size), k (hash functions), and actual FPR
    """
    # Optimal bit array size
    m = - (n * math.log(p)) / (math.log(2) ** 2)
    m = math.ceil(m)

    # Optimal number of hash functions
    k = (m / n) * math.log(2)
    k = math.ceil(k)

    # Actual FPR with rounded values
    actual_p = (1 - math.exp(-k * n / m)) ** k

    return {
        'bit_size': m,
        'hash_functions': k,
        'bits_per_element': m / n,
        'actual_fpr': actual_p,
        'expected_fpr': p
    }

# Example: Design a filter for 1 million items with 1% FPR
params = calculate_bloom_filter_params(n=1_000_000, p=0.01)
print(f"Bit array size: {params['bit_size']:,} bits ({params['bit_size']/8/1024/1024:.2f} MB)")
print(f"Hash functions: {params['hash_functions']}")
print(f"Bits per element: {params['bits_per_element']:.2f}")
print(f"Actual FPR: {params['actual_fpr']*100:.3f}%")

Sizing Quick Reference:

Elements (n)	Target FPR	Bit Size (m)	Hash Functions (k)	Memory (bits/elem)
10,000	1%	95,784	7	9.58
10,000	0.1%	143,776	10	14.38
100,000	1%	957,840	7	9.58
100,000	0.1%	1,437,760	10	14.38
1,000,000	1%	9,578,400	7	9.58
1,000,000	0.1%	14,377,600	10	14.38

Important Notes:

• Always round up the bit size (m) to meet your FPR target
• Rounding k down slightly can give a more practical result with minimal FPR increase
• For very low FPRs (below 0.1%), memory requirements grow rapidly
• The bits per element converges to about 9.6 for 1% FPR regardless of n

Core Concepts

Space Efficiency

Bloom filters achieve their space efficiency through bit packing. Storing N elements with a 1% false positive rate requires only about 9.6 bits per element.

def bits_per_element(false_positive_rate: float) -> float:
    return -math.log2(false_positive_rate) / math.log(2)

print(f"1% FPR: {bits_per_element(0.01):.1f} bits/element")
print(f"0.1% FPR: {bits_per_element(0.001):.1f} bits/element")
print(f"10% FPR: {bits_per_element(0.10):.1f} bits/element")

For comparison, a hash set storing 1 million 8-byte elements needs roughly 64 bits per element just for pointers, plus overhead.

Use Cases in Distributed Systems

Cache Filtering

The most common use case. Before querying a cache or database, check the Bloom filter to avoid unnecessary queries:

class CacheWithBloomFilter:
    def __init__(self, cache: Cache, bloom: BloomFilter):
        self.cache = cache
        self.bloom = bloom

    def get(self, key: str) -> Optional[bytes]:
        key_bytes = key.encode()

        if not self.bloom.might_contain(key_bytes):
            return None

        return self.cache.get(key)

    def set(self, key: str, value: bytes):
        self.cache.set(key, value)
        self.bloom.add(key.encode())

    def invalidate(self, key: str):
        self.cache.invalidate(key)

If the Bloom filter says the key is not in the cache, you can skip the cache lookup entirely. If it says the key might be in the cache, you query the cache. False positives cause a few unnecessary cache queries. True negatives save thousands of unnecessary queries.

Database Query Optimization

Google Bigtable, Cassandra, and HBase use Bloom filters to avoid reading SSTables that cannot contain a key:

class SSTableWithBloomFilter:
    def __init__(self, data_file: str, bloom: BloomFilter, index: Index):
        self.bloom = bloom
        self.index = index
        self.data_file = data_file

    def get(self, key: bytes) -> Optional[bytes]:
        if not self.bloom.might_contain(key):
            return None

        offset = self.index.lookup(key)
        if offset is None:
            return None

        return self.read_from_offset(offset)

If you have 100 SSTables and a key maps to 3 of them based on the index, the Bloom filter tells you that 2 of those 3 definitely do not contain the key. You only read 1 SSTable instead of 3.

For more on database storage, see Database Scaling.

Distributed Systems Coordination

Service discovery systems use Bloom filters to track which services have registered:

class ServiceRegistry:
    def __init__(self):
        self.services = {}
        self.bloom = BloomFilter(expected_elements=10000, false_positive_rate=0.01)

    def register(self, service_name: str, instance: ServiceInstance):
        if service_name not in self.services:
            self.services[service_name] = []
        self.services[service_name].append(instance)
        self.bloom.add(f"{service_name}:{instance.id}".encode())

    def might_exist(self, service_name: str) -> bool:
        return self.bloom.might_contain(service_name.encode())

    def get_instances(self, service_name: str) -> list[ServiceInstance]:
        if not self.might_exist(service_name):
            return []
        return self.services.get(service_name, [])

Web Cache Sharing

Content delivery networks use Bloom filters to track which URLs have been cached:

class CDNCache:
    def __init__(self, bloom: BloomFilter):
        self.bloom = bloom
        self.cache = {}

    def might_be_cached(self, url: str) -> bool:
        return self.bloom.might_contain(url.encode())

    def cache_response(self, url: str, response: bytes):
        self.cache[url] = response
        self.bloom.add(url.encode())

    def get_response(self, url: str) -> Optional[bytes]:
        if not self.might_be_cached(url):
            return None
        return self.cache.get(url)

When a user requests a URL, the edge server checks its Bloom filter. If the filter says the URL might be cached, the server checks its cache. If the filter says the URL is definitely not cached, the server forwards the request to origin without checking the cache.

Web Cache Sharing in Bloom Filters

Scaling Bloom Filters

Horizontal Scaling

For very large datasets, distribute elements across multiple Bloom filters:

class DistributedBloomFilter:
    def __init__(self, num_filters: int, expected_elements: int, fpr: float):
        self.filters = [
            BloomFilter(expected_elements // num_filters, fpr)
            for _ in range(num_filters)
        ]

    def _get_filter_index(self, element: bytes) -> int:
        hash_value = int.from_bytes(
            hashlib.sha256(element).digest()[:4],
            byteorder='big'
        )
        return hash_value % len(self.filters)

    def add(self, element: bytes):
        self.filters[self._get_filter_index(element)].add(element)

    def might_contain(self, element: bytes) -> bool:
        return self.filters[self._get_filter_index(element)].might_contain(element)

Advanced Variants

Cuckoo Filters

Cuckoo filters handle deletions without the memory overhead of counting filters. They use cuckoo hashing, where each element maps to two possible buckets. When inserting, if either bucket has room, the element goes there. If both are full, one element is evicted to its alternate bucket. This eviction chain continues until all elements fit.

Cuckoo filters support deletions, use slightly less space for the same false positive rate, and have near-constant lookup time. The tradeoff is a more complex implementation and a bounded capacity (you must specify the expected maximum number of elements).

class CuckooFilter:
    def __init__(self, capacity: int, bucket_size: int = 4):
        self.capacity = capacity
        self.bucket_size = bucket_size
        self.buckets = [[None] * bucket_size for _ in range(capacity)]
        self.fingerprint_size = 8  # bits per fingerprint

    def _hash(self, element: bytes) -> tuple[int, int]:
        import hashlib
        h = int.from_bytes(hashlib.sha256(element).digest()[:8], 'big')
        h1 = h % self.capacity
        h2 = h1 ^ ((h >> 16) % self.capacity)
        return h1, h2

    def _fingerprint(self, element: bytes) -> int:
        import hashlib
        return int.from_bytes(
            hashlib.sha256(element).digest()[:self.fingerprint_size // 8],
            'big'
        )

    def add(self, element: bytes) -> bool:
        h1, h2 = self._hash(element)
        fp = self._fingerprint(element)

        if self._insert(h1, fp) or self._insert(h2, fp):
            return True

        # Eviction chain
        idx, alt_idx = h1, h2
        for _ in range(self.capacity * self.bucket_size):
            old_fp = self.buckets[idx][0]
            self.buckets[idx][0] = fp
            fp = old_fp
            idx, alt_idx = alt_idx, idx ^ ((fp >> 16) % self.capacity)
            if self._insert(alt_idx, fp):
                return True

        return False

    def _insert(self, idx: int, fp: int) -> bool:
        for i in range(self.bucket_size):
            if self.buckets[idx][i] is None:
                self.buckets[idx][i] = fp
                return True
        return False

    def might_contain(self, element: bytes) -> bool:
        h1, h2 = self._hash(element)
        fp = self._fingerprint(element)
        return fp in self.buckets[h1] or fp in self.buckets[h2]

    def remove(self, element: bytes) -> bool:
        h1, h2 = self._hash(element)
        fp = self._fingerprint(element)
        for idx in [h1, h2]:
            if fp in self.buckets[idx]:
                self.buckets[idx].remove(fp)
                return True
        return False

Cuckoo vs Bloom:

Aspect	Bloom Filter	Cuckoo Filter
Delete support	No	Yes
Space efficiency	~9.6 bits/elem @ 1% FPR	~7-8 bits/elem @ 1% FPR
Lookup time	O(k)	O(1) to O(bucket_size)
Insertion	Simple	Complex (eviction chain)
Maximum capacity	Unlimited	Must be specified
Standard libraries	Many	Fewer

Cuckoo filters work better when you need deletions or slightly better space efficiency. Bloom filters are simpler and have wider library support.

Counting Bloom Filters

Standard Bloom filters cannot delete elements. Counting filters use counters instead of bits:

class CountingBloomFilter:
    def __init__(self, expected_elements: int, false_positive_rate: float):
        self.bloom = BloomFilter(expected_elements, false_positive_rate)
        self.counters = [0] * self.bloom.size

    def add(self, element: bytes):
        for pos in self.bloom._get_hash_positions(element):
            self.counters[pos] += 1

    def remove(self, element: bytes):
        for pos in self.bloom._get_hash_positions(element):
            if self.counters[pos] > 0:
                self.counters[pos] -= 1

    def might_contain(self, element: bytes) -> bool:
        return all(self.counters[pos] > 0
                       for pos in self.bloom._get_hash_positions(element))

Counting filters use more memory (4 bytes per counter instead of 1 bit per cell) but support deletions.

Topic-Specific Deep Dives

Production Libraries Overview

Do not implement Bloom filters from scratch for production use. Use well-tested libraries that handle edge cases and are optimized.

RedisBloom

RedisBloom provides Bloom filters, Cuckoo filters, and other probabilistic data structures as Redis modules:

# Add RedisBloom to Redis
docker run -d -p 6379:6379 redislabs/rebloom:latest

# Use with redis-cli
BF.ADD myfilter item1
BF.EXISTS myfilter item1
BF.EXISTS myfilter item2

import redis

r = redis.Redis()
r.bf().add('myfilter', 'item1')
r.bf().exists('myfilter', 'item1')  # True
r.bf().exists('myfilter', 'item2')  # False

RedisBloom works well in distributed deployments since the filter lives in Redis. Multiple application servers share the same filter without local replication.

Guava BloomFilter

Google’s Guava library provides Bloom filters for Java applications:

import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;

BloomFilter<User> filter = BloomFilter.create(
    Funnels.byteArrayFunnel(),
    1_000_000,  // expected insertions
    0.01        // false positive probability
);

filter.put(userId);
if (filter.mightContain(userId)) {
    // Query database to confirm
}

Guava’s implementation is efficient and fast. It serializes to byte arrays for distributed use cases.

Python Libraries

For Python, pybloom-live provides a simple Bloom filter implementation:

from pybloom import BloomFilter

f = BloomFilter(capacity=1000, error_rate=0.01)
f.add('item1')
print('item1' in f)  # True
print('item2' in f)  # False

For Cuckoo filters in Python, use cuckoofilter:

from cuckoofilter import CuckooFilter

cf = CuckooFilter(capacity=1000)
cf.insert('item1')
cf.exists('item1')  # True
cf.remove('item1')
cf.exists('item1')  # False

Hash Functions for Bloom Filters

The hash function choice affects both performance and distribution quality. For Bloom filters, you need independent hash functions that spread bits uniformly.

import hashlib
import time

def benchmark_hash(data: bytes, iterations: int = 100_000):
    """Compare hash function performance for Bloom filter use."""
    results = {}

    # MurmurHash3 (via mmh3)
    try:
        import mmh3
        start = time.time()
        for _ in range(iterations):
            for i in range(10):  # 10 hash functions
                mmh3.hash(data, seed=i)
        results['MurmurHash3'] = time.time() - start
    except ImportError:
        results['MurmurHash3'] = 'not installed'

    # xxHash
    try:
        import xxhash
        start = time.time()
        for _ in range(iterations):
            for i in range(10):
                xxhash.xxh64(data, seed=i).int64()
        results['xxHash64'] = time.time() - start
    except ImportError:
        results['xxHash64'] = 'not installed'

    # SHA-256
    start = time.time()
    for _ in range(iterations):
        for i in range(10):
            h = hashlib.sha256(data + str(i).encode()).digest()[:8]
    results['SHA-256'] = time.time() - start

    # MD5
    start = time.time()
    for _ in range(iterations):
        for i in range(10):
            h = hashlib.md5(data + str(i).encode()).digest()[:4]
    results['MD5'] = time.time() - start

    return results

Performance comparison (100k iterations, 10 hash functions each):

Hash Function	Speed	Collision Resistance	Recommendation
xxHash64	Fastest	Low (non-cryptographic)	Best for Bloom filters
MurmurHash3	Fast	Low (non-cryptographic)	Good alternative
MD5	Slow	Broken (cryptographic)	Do not use
SHA-256	Slowest	High	Only if attacker resistance needed

For Bloom filters, use xxHash or MurmurHash3. The non-cryptographic nature does not matter since attackers cannot control element placement unless they control the hash function input. If you need attacker resistance, SHA-256 prevents crafted collision attacks but adds performance overhead.

Monitoring and Health Checks

Filter Saturation Monitoring

As elements are added, a Bloom filter’s bit array fills up and the false positive rate climbs. Monitoring saturation helps you recreate filters before performance degrades.

def bit_array_fill_rate(bloom: BloomFilter) -> float:
    """Return fraction of bits set to 1."""
    return sum(bloom.bit_array) / len(bloom.bit_array)

def estimated_fpr(bloom: BloomFilter, actual_n: int) -> float:
    """
    Estimate actual FPR given current fill rate.
    n = actual elements inserted
    m = bit array size
    k = hash functions
    """
    m = bloom.size
    k = bloom.hash_count
    fill_rate = sum(bloom.bit_array) / m

    # Actual FPR approximation based on observed fill
    return (1 - (1 - 1/m) ** (k * actual_n)) ** k

def check_filter_health(bloom: BloomFilter, expected_n: int,
                       target_fpr: float, actual_n: int) -> dict:
    """
    Check if a Bloom filter is still within acceptable parameters.
    """
    fill_rate = bit_array_fill_rate(bloom)
    current_fpr = estimated_fpr(bloom, actual_n)

    return {
        'fill_rate': fill_rate,
        'estimated_fpr': current_fpr,
        'target_fpr': target_fpr,
        'is_healthy': current_fpr <= target_fpr * 1.5,  # 50% margin
        'recommendation': 'recreate' if fill_rate > 0.5 else 'ok'
    }

# Monitor in production
def monitor_bloom_filter(bloom: BloomFilter, expected_n: int,
                         target_fpr: float, actual_n: int):
    health = check_filter_health(bloom, expected_n, target_fpr, actual_n)

    if not health['is_healthy']:
        alert(f"Bloom filter FPR degraded: {health['estimated_fpr']:.3%} "
              f"(target: {target_fpr:.3%})")

    if health['fill_rate'] > 0.5:
        alert(f"Bloom filter 50% full, consider recreating with larger size")

    if health['recommendation'] == 'recreate':
        alert(f"Bloom filter saturation threshold exceeded, recreate recommended")

Saturation thresholds:

Fill Rate	FPR Impact	Action
< 30%	Near target	Healthy
30-50%	Slight increase	Monitor closely
50-70%	Noticeable	Plan recreation with 2x expected elements
> 70%	Severe	Recreate immediately

For production systems, track fill rate as a time series and alert when the trend projects crossing 50% within a planning horizon. Recreating filters requires either a cold start (new empty filter, potential cache stampede) or a background reload from the source of truth.

Decision Guide

When to Use

Bloom filters work well when you need to check membership against large sets where storing all elements in memory would be expensive. A 1-5% false positive rate is acceptable for cache sharding and database query optimization. The space savings are real: a few bytes per element versus the full element size. O(k) hash lookups stay fast regardless of element count.

When Not to Use

Bloom filters do not work when false positives are unacceptable. Password breach checking is the classic example: telling a user their password is compromised when it is not is worse than telling them it is safe. Cuckoo filters handle deletions if you need them. You cannot list elements from a Bloom filter, only query membership. And if your dataset is small enough to store directly, just use a hash set.

Production Failure Scenarios

Failure	Impact	Mitigation
Bloom filter fill rate exceeds design threshold	False positive rate climbs beyond intended bound; cache sharding breaks down	Monitor bit array fill rate; recreate filter with larger expected_elements when fill_rate > 50%; size for 2x expected capacity
Security attacker fills filter with false positives	Cache sharding returns false positives for all keys; cache hit rate collapses	Authenticate filter updates; use a separate write-only filter for untrusted input; rate-limit additions
Hash collision degrades filter uniformity	Uneven bit distribution causes higher-than-expected false positive rate	Use k independent cryptographic hash functions (or xxHash/MurmurHash family with different seeds); avoid SHA-1 for large n due to performance
Cold start after filter loss	New filter starts empty; every query returns negative; database sees flood of “miss” queries	Persist filter to durable storage; load on startup; bootstrap from source database
Synchronization mismatch between filter and source	Filter not updated when source data changes; stale membership answers cause false positives	Re-replicate filter after source writes (read-your-writes consistency); use increment Bloom filter for append-only data
Counting Bloom filter counter overflow	Counter reaches max value and wraps; other elements’ bits corrupted	Size counters for expected maximum element frequency (use 4-bit counters for typical use cases); monitor for saturation

Common Pitfalls / Anti-Patterns

Fundamental Constraints

False Positives

Bloom filters can return false positives. If your use case cannot tolerate false positives, Bloom filters are not the right choice.

Cannot Delete Elements

Standard Bloom filters cannot delete elements. Deleting an element might unset bits that other elements depend on. Use Counting Bloom filters if you need deletions.

Cannot List Elements

You cannot retrieve elements from a Bloom filter, only check membership. If you need to list all elements, use a different data structure.

Configuration Pitfalls

Parameter Sensitivity

Choosing the wrong size or hash function count affects performance. Use the formulas in the implementation section to calculate optimal parameters.

Not Recreating Filters After Too Many Elements

Bloom filters have fixed size. When you insert too many elements, the false positive rate climbs past the designed threshold. Monitor the fill rate and recreate filters when necessary.

def fill_rate(bloom: BloomFilter) -> float:
    return sum(bloom.bit_array) / len(bloom.bit_array)

if fill_rate(bloom) > 0.5:
    bloom = BloomFilter(expected_elements * 2, false_positive_rate)

Operational and Security Concerns

Using Wrong Hash Functions

The hash functions must be independent and uniformly distributed. MD5 and SHA-1 work but are slow. For performance, use faster hash functions like xxHash or MurmurHash.

Ignoring Security Implications

If attackers can add elements to your Bloom filter, they can force the false positive rate to 100%, disabling the filter. For security-sensitive applications, use an authenticated Bloom filter that prevents unauthorized additions.

Quick Recap Checklist

• Bloom filters use M bits and K hash functions to represent N elements
• “No” means definitely not present; “Yes” means possibly present (check source)
• Sizing formula: m = -(n × ln(p)) / (ln(2)²), k = (m/n) × ln(2)
• At 1% FPR, expect ~9.6 bits per element
• Monitor fill rate and recreate filters when bit saturation exceeds 50%
• Cannot delete with standard Bloom filters—use counting filters if needed
• Choose xxHash or MurmurHash over SHA-1 for performance in non-adversarial scenarios
• RedisBloom and Guava BloomFilter are production-ready implementations

Interview Questions

For more on data structures for distributed systems, see Merkle Trees, Database Scaling, and Caching Strategies.

Further Reading

• Merkle Trees - Cryptographic hashing for set reconciliation
• Database Scaling - Scaling storage layers
• Caching Strategies - Cache patterns for distributed systems
• RedisBloom Documentation - Production Bloom filter implementation
• Guava BloomFilter - Java Bloom filter library

Conclusion

Bloom filters answer “might this element be in the set?” with minimal memory—roughly 9.6 bits per element at 1% false positive rate. They never produce false negatives (a “no” answer is always correct), but they can yield false positives (a “yes” might be wrong). The three knobs you control are bit array size, number of hash functions, and expected element count—pick two and the formulas give you the third. Use them to filter cache misses before database queries, skip reading SSTables that cannot contain a key, or pre-check membership before expensive operations. If you need deletions, count the bits instead of just setting them. If attackers can fill your filter with false positives, use authenticated additions or rate limiting.