Topic 10.2
Billion-User Membership Service and a 2-Billion Product Catalogue
In one line
For 1B users at 100K queries/sec, a local filter per API node answers most "does this user exist?" checks in microseconds, Redis caches hot records, and the database stays authoritative. For a 2B-ID catalogue where most requests are invalid, a filter is the cheapest membership accelerator: ~2.4 GB at 1%.
Think of it like this
A national ID office. The front counter has a compact register that instantly rules out numbers that were never issued; only plausible numbers go to the records room.
Key ideas
- 01
Sizing: 1B users at 0.1% ≈ 1.8 GB; at 1% ≈ 1.2 GB. 2B product IDs at 1% ≈ 2.4 GB.
- 02
Placement: 100K queries/sec across, say, 50 API nodes: local filters (1.8 GB each, 90 GB fleet-wide) avoid a shared hot key and keep latency tiny; updates via Kafka; snapshots for startup.
- 03
Hot IDs: the filter is equally fast for hot and cold IDs; hot IDs' data lives in Redis; very hot IDs in an in-process cache.
- 04
Updates: new users flow outbox → Kafka → every node's filter; watermark bypass for brand-new IDs.
- 05
Failure: node without a loaded filter isn't ready (readiness probe) until loaded; if the filter pipeline is down, nodes keep their last good filter plus the bypass.
Code & diagrams
Interview problem
The problem
Membership service: 1B users, 100K queries/sec
Design a membership service answering "does user X exist?" for 1 billion users at 100K queries/sec, using a Bloom filter, Redis and the database. Discuss memory, FPR, hot IDs, failure and updates. Then adapt it for a 2-billion product catalogue where most requests are invalid.
Explain it without notes
Why check Redis after a "maybe" rather than going straight to the database?
Practice
Compute fleet memory and snapshot transfer for 1B users at 0.1% with 80 API nodes.
Trade-offs
- ↔
Local filters cost fleet memory but keep latency and shared-dependency risk low.
Done when you can
I can design high-QPS membership services and catalogue accelerators with Bloom filters.