Command Palette

Search for a command to run...

Hectal
Phase 6Intermediate7 of 12 in Bloom Filters

Bloom Filters with Redis and Databases

The membership accelerator in front of a database, cache penetration defence against random-ID attacks, RedisBloom operations, local vs shared filters, and a username availability API.

The most common production use of Bloom filters is protecting a database from requests for things that don't exist. This phase builds that design end to end, including where the filter lives and what happens when it's unavailable.

Throughout: the filter is never the source of truth. It only lets you skip lookups that would certainly fail.

0/4 · 0%
4 topics ~32 min 6 code blocks & diagrams
Start with the first topic
1
6.1

The Membership Accelerator and Cache Penetration

Put a Bloom filter of valid IDs in front of the cache and database: "definitely absent" returns 404 immediately, "maybe" continues to Redis and then the database. It neutralises cache penetration from random or nonexistent IDs, where caching can't help because every key is new.

9 min 1 diagram 1 code practice

2
6.2

RedisBloom: Commands, Capacity, and Operations

Redis provides Bloom filters as a native type (Redis 8, RedisBloom module, or valkey-bloom): BF.RESERVE with error rate and capacity, BF.ADD/BF.MADD, BF.EXISTS/BF.MEXISTS, and scaling by expansion. Operate it like any Redis data: capacity planning, persistence, replication, and monitoring with BF.INFO.

7 min 1 code practice

3
6.3

Local vs Shared Filters Across Many Instances

Each app instance can hold a local copy (nanosecond lookups, memory × instances, update fan-out) or all instances can query one shared Redis filter (one copy, one network hop per lookup, Redis as a dependency). Choose by filter size, update rate, latency budget and failure behaviour, and often combine them.

8 min 1 code practice

4
6.4

Designing a Username Availability API

A Bloom filter of taken usernames answers "definitely available" instantly for most checks; "maybe taken" goes to the database. Correctness still comes from a unique constraint at registration, and normalisation (case, Unicode NFKC, confusables) must be identical when inserting and checking.

8 min 1 diagram 1 code practice