BloomCraft unifies 12 Bloom filter variants under one Rust API

BloomCraft lands in a familiar Rust headache: picking a Bloom filter that fits your workload without pulling in three crates and a pile of trade-offs you only discover under load. The project wraps twelve variants behind one BloomFilter trait, so you can compare memory footprint, false-positive behavior, deletion support, and concurrency patterns from the same API surface. That is useful only if you actually need the comparison, and that is where BloomCraft feels more like a decision guide than a crate announcement.

Why Bloom filters still matter

Bloom filters have been around since Burton H. Bloom introduced them in 1970, and the basic pitch has not changed much: they answer approximate membership questions quickly and compactly. You get false positives, but not false negatives for items that were actually inserted, which makes them ideal when an exact hash table would burn too much memory for too little gain. Bloom’s original framing around large dictionaries still maps cleanly to modern Rust workloads where a quick “probably not” can save a lot of expensive lookups.

That old trade-off is why Bloom filters keep showing up in caches, rate limiters, and membership indexes. They are not a silver bullet, and they are not meant to be one. They are the right tool when you can tolerate a small error rate in exchange for lower space usage and fewer downstream reads.

What BloomCraft actually unifies

BloomCraft’s central move is to put a broad family of implementations behind a single BloomFilter trait. The crate includes counting, scalable, partitioned, register-blocked, tree, sharded, striped, atomic scalable, and atomic partitioned variants, along with reference implementations kept for teaching and comparison. That gives you one place to compare designs that usually live in separate crates or separate papers.

That matters because the Rust ecosystem already has Bloom-filter crates, but many of them expose only one or two shapes. The older bloom and bloomfilter crates document simpler Bloom and counting-Bloom implementations, while fastbloom pushes in a different direction with full concurrency support and configurable hashing. BloomCraft sits in the middle and tries to make the design space visible instead of hiding it behind a single default.

The trade-offs that decide the winner

The first question is not “which Bloom filter is fastest,” because speed depends on what you are paying for elsewhere. A classic Bloom filter is space-efficient and simple, but it cannot delete entries cleanly. Counting Bloom filters solve that by replacing the bit vector with counts, which lets you support deletions and count-threshold use cases, but you pay for the extra bookkeeping and memory overhead.

Scalable Bloom filters are the other big escape hatch. The version proposed in 2007 by Paulo Sérgio Almeida, Carlos Baquero, Nuno Preguiça, and David Hutchison was designed to grow with the set while keeping a bounded false-positive probability, which is exactly what you want when you do not know your final cardinality in advance. If you are over-sizing a fixed filter just to avoid reallocation, scalable variants can be the cleaner answer.

Partitioned, register-blocked, and tree variants are about squeezing better locality and access patterns out of the same basic idea. Those designs can be worth it when the workload is hot enough that cache behavior matters more than the simplest possible implementation. If you are comparing filters for a production path that is already memory-sensitive, these are not academic distinctions, they are the difference between a filter that stays invisible and one that starts showing up in profiles.

Concurrency is the other big decision

BloomCraft treats concurrency as a first-class axis, which is the right call for Rust. The project separates three models: external locking around &mut self, atomic compare-and-swap directly on the bit words, and interior-mutability approaches such as sharding and striping. Each one buys you something different, and none of them is free.

External locking is the simplest to reason about, and it is often the cleanest choice when writes are rare or contention is low. Atomic bit-word updates reduce lock overhead, but they make the implementation more specialized and can still bottleneck on hot bits. Sharding and striping split the structure so multiple threads can work with less interference, which is the direction you want when the filter sits on a hot path and updates are frequent.

That concurrency focus lines up with the niche Bloom-filter work already happening in Rust. fastbloom advertises full concurrency support, while BloomCraft tries to expose multiple synchronization strategies under one abstraction instead of forcing you to choose a whole crate just to change the locking model. For heavily concurrent services, that makes the comparison much more honest.

Hashing and API ergonomics are not minor details

BloomCraft also leans on type-state builders so misconfigured filters fail at compile time. That is the sort of Rust ergonomics that actually helps in this space, because Bloom filters are extremely sensitive to configuration: the false-positive rate depends on the bit array size, the number of inserted items, and the number of hash functions. If you get the setup wrong, the API should catch it before you ship a filter that quietly performs badly.

Hashing is pluggable too. SipHash is the default, with faster alternatives like WyHash and XXH3 available behind feature flags, which gives performance-conscious users room to tune for their workload. That flexibility matters because Michael Mitzenmacher and Adam Kirsch showed in 2002 that two hash functions are enough to simulate more Bloom-filter hashes without losing asymptotic false-positive performance, so there is real room to balance throughput against CPU cost.

When one abstraction helps, and when a single implementation is better

BloomCraft makes sense when your real task is choosing between designs, not just using one. If you are evaluating whether you need deletions, whether your set will grow, whether cache locality matters, and whether multiple threads will mutate the structure, having twelve variants under one trait saves time and makes the trade-offs visible. It is especially useful when you want to compare a classic reference implementation against counting, scalable, atomic, or striped forms without relearning a new crate each time.

A single specialized implementation is still the better call when the workload is already fixed and well understood. If you know you need one concurrency model, one hash strategy, and one memory profile, fewer abstractions usually mean less cognitive overhead and less room for misconfiguration. BloomCraft is strongest when you are still asking the right questions, and the moment those answers settle down, the old Bloom-filter rule still applies: pick the simplest design that meets your false-positive budget, memory ceiling, and contention profile.