We’ve spent all week talking about Redis Hashes, Bloom Filters, and Tries.
But let’s be real: 90% of the time, you’re just hitting a PostgreSQL Index.
Ever wondered what’s actually happening when you add @unique or CREATE INDEX? It’s not just a "magic list." It’s almost always a B+ Tree.
What is a B+ Tree?
Think of it as a perfectly balanced, multi-level library.
In a normal Binary Tree, you only have two branches. In a B+ Tree, each "node" can have hundreds of branches. This means even if you have BILLIONS of records, the database only needs to look at 3 or 4 levels to find your specific data.
Why B+ Trees are the GOAT:
- Range Queries: Unlike Redis Hashes (which are bad at "give me users with ID 10 to 50"), B+ Trees keep all their data at the "leaves" in a linked list. You can slide across them instantly.
- Disk Friendly: Databases don't live in RAM (usually). B+ Trees are designed to be read from your SSD in "blocks," making them incredibly efficient for physical storage.
- Balanced Performance: Whether you’re searching for the 1st record or the 1,000,000th, the time taken ($O(\log n)$) is virtually the same.
The Reality Check:
- Redis Hash: Instant, but expensive (RAM).
- B+ Tree (SQL Index): Very fast, cheaper (Disk), and handles ranges like a pro.
This is why I keep saying: For my 10k user projects, a well-indexed Postgres table is more than enough. You don't need to over-engineer until you actually have the traffic to justify it.
Series Wrap-up:
We’ve covered:
- Redis Hashes (Storage efficiency)
- Bloom Filters (The Bouncer)
- Trie Structures (Prefix/Search)
- B+ Trees (The Foundation)
The most important skill isn't knowing how to build these—it's knowing WHICH one to pick for your specific problem.
That’s a wrap on this System Design series!
Which of these four surprised you the most? Or is there another structure I missed? Let’s nerd out in the comments!
Top comments (0)