incident.io had an API that took up to 5 seconds at the 95th percentile. One change — a Bloom filter in front of their database — made it 16× faster. This video breaks down exactly what a Bloom filter is, how it works, where it fits into a real system, and where it quietly breaks down. No whiteboard-only theory: we walk through the real incident.io architecture and the tradeoffs they chose.
By the end you'll know:
• Why a Bloom filter never says "yes" — and why that's the point
• How 512 bits and 7 hash functions can screen out 99% of work
• How this pattern shows up in storage engines and CDNs
• When NOT to use one
━━━━━━━━━━━━━━━━━━━━━━━━━━━
? Get the biweekly newsletter
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Deep dives on systems + scaling tricks like this one, straight to your inbox:
? https://techwithnikola.com/newsletter
━━━━━━━━━━━━━━━━━━━━━━━━━━━
? Links & references
━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Math-proof code (Python): https://gist.github.com/freezing/9acd085cef3da2c2a28c2647d55ef451
• incident.io engineering blog — https://incident.io/blog/bloom-filters
• Bloom's original 1970 paper — https://dl.acm.org/doi/10.1145/362686.362692
• More from me — https://techwithnikola.com
━━━━━━━━━━━━━━━━━━━━━━━━━━━
⏱ Chapters
0:00 Intro — the 16× mystery
0:22 What a Bloom filter actually does
1:23 How it works — bits, hashes, and "maybe"
2:29 What incident.io did
5:10 How they fixed it
7:02 The math behind it
8:11 Where else Bloom filters show up
9:36 A critical take — when they fall apart
10:59 Wrap up