When is a shipped bloom filter the wrong answer for a client-side blocklist, and what would you ship instead?

## Start from who pays for a wrong answer The memory argument is the easy part and it is not the decision. A filter converts a large exact question into a cheap probabilistic one with a one-sided error, and the whole judgment is whether the system has somewhere to put that error. Ask, before anything else: when the structure says 'possibly present', what happens next? If the answer is 'we make a call to the authoritative service, or read the file, and find out', the design works, and the filter's job is to remove the ninety-something percent of queries that never needed the check. If the answer is 'we show a warning', 'we block the request', 'we lock the account', 'we decline the transaction' — the false positives *are* user-visible harm, deterministically, for the unlucky inputs, forever, because the same input always gets the same answer until the filter is rebuilt. A one-in-ten-thousand rate sounds fine until you multiply it by a fleet's daily query volume and notice you are producing a steady stream of wrongly-blocked users with no path to appeal that a support engineer can even reproduce. ## The case where it clearly wins A client-side check against a very large blocklist of remote addresses is close to the ideal case. The list is enormous relative to what you can ship to a device; the entries are long strings, so the exact structure's footprint grows with length while the filter's does not; the traffic is overwhelmingly negative, so almost every query is answered exactly and locally; and a hit can be confirmed with a single lookup against a service before anything user-visible happens. Here you defend the tradeoff to a skeptic on those four points, in that order, and you note that shipping the exact set is not merely bigger — it may be impossible within the device's storage and update budget, and pushing every check to a server costs a round trip on *every* navigation instead of on a small fraction. ## The cases where it loses - **No confirmation path.** The positive is the decision. Ship an exact structure, or move the decision server-side, or accept a smaller curated list you can hold exactly. - **You need more than membership.** A blocklist entry usually wants a reason, a category, an expiry, a severity. The filter answers one bit about one input and can carry no payload, so if the product needs 'why', you need a real map for at least the entries that matter. - **The list is small enough already.** If an exact compact structure fits the budget, take exactness for free. The filter earns its keep only when memory genuinely binds. - **Frequent, fine-grained removals.** No deletion in the standard form, and a counting variant multiplies memory by several times. If entries churn hourly and you cannot rebuild and redistribute on that cadence, choose differently. - **Adversarial input with public parameters.** If the array and hash functions ship to clients, an attacker can search for inputs that light up all the required positions and use them to drive traffic into the confirmation path or the block path at will. Per-release keyed hashing raises the cost of that; it does not remove the class of problem, and a system where the fallback path is the fragile one should not be gated this way. ## What growth does and does not fix A skeptic will ask what happens at ten times the list size. Be honest: at a fixed error rate the memory is *linear* in the element count, so ten times the list is ten times the bits. The filter changes the constant — often by an order of magnitude against an exact set — but it does not change the growth. The levers when you hit the ceiling are: loosen the error rate, which costs only a few bits per element per order of magnitude and so gives you very little room; ship only the highest-value subset locally and let the tail go to the server; partition the key space and ship the partitions a client actually needs; or move the check server-side entirely and pay the latency. Naming those in order, with the memory ceiling per device as the binding constraint, is the answer an interviewer is looking for at this level. ## The operational commitment Shipping one is a commitment, not a data-structure choice. It obliges the team to size for the final element count rather than today's, since overfilling silently degrades the rate; to record the parameters alongside the artefact so a future engineer can rebuild it; to run a rebuild-and-redistribute pipeline because entries cannot be removed in place; and to measure the observed false-positive rate — every confirmed-negative hit is a sample — against the design target, alarming on drift. If nobody will own that, the clever compact artefact becomes a mystery blob that slowly gets worse, and the right recommendation is the boring exact structure that any engineer can reason about. ## How to close the argument The defensible position is not 'filters are great' or 'filters are risky'. It is: this workload is overwhelmingly negative, the list dwarfs the memory budget, a hit has a cheap confirmation, and we will own the sizing and rebuild discipline — therefore the filter. Change any one of those four clauses and the recommendation changes with it.