Data Structures on

Lesson 12: Ring Buffers — Fixed-size queues for real-time systems

Mon, 16 Sep 2024 00:00:00 +0000

The ring buffer is the data structure that makes real-time systems possible. Audio processing, network packet capture, kernel I/O buffers, metrics collection — anywhere you have a producer and a consumer that need to exchange data with zero allocation and bounded latency, you’ll find a ring buffer.

It’s also one of the most elegant structures in systems programming: a fixed-size array, two indices, and one invariant. Let me show you how it works and why it appears everywhere from Linux kernel drivers to Disruptor (the LMAX exchange’s million-transactions-per-second queue).

Lesson 11: Skip Lists — How Redis sorted sets work

Tue, 03 Sep 2024 00:00:00 +0000

Redis chose skip lists for its sorted set implementation, and that choice is more interesting than it first appears. When you have ZADD, ZRANGE, and ZRANK all needing to run at O(log n), you might reach for a balanced BST. But Redis chose a probabilistic alternative that’s simpler to implement, easier to reason about in concurrent contexts, and performs comparably in practice.

Understanding skip lists taught me something important about engineering tradeoffs: sometimes “good enough with simpler code” beats “optimal but complex.”

Lesson 10: Bloom Filters — Probably yes, definitely no

Mon, 19 Aug 2024 00:00:00 +0000

There’s a beautiful data structure that will tell you one of two things: “definitely not in the set” or “probably in the set.” That asymmetry — where false negatives are impossible but false positives are allowed — turns out to be useful in an enormous number of production scenarios.

Bloom filters use a fraction of the memory of a hash set, and the math behind their false positive rate is surprisingly elegant. Once you understand them, you’ll see why databases, CDNs, and distributed caches reach for them constantly.

Lesson 9: Tries — Prefix matching, autocomplete, routing tables

Tue, 06 Aug 2024 00:00:00 +0000

When you type “ath” into a search box and it suggests “atharva,” “athens,” and “athletics,” that’s a trie. When an IP packet arrives at a router and the router decides which interface to forward it to, that’s a trie (specifically a Patricia trie). When your web framework matches /api/users/:id against an incoming URL, the fast implementations use a trie.

Tries (pronounced “try,” from “retrieval”) are specialized trees for string keys. They trade memory for speed in prefix-matching scenarios, and they make certain string operations fundamentally faster than any other structure.

Lesson 8: Graphs — You're solving graph problems without knowing it

Tue, 23 Jul 2024 00:00:00 +0000

Most engineers don’t think of themselves as solving graph problems. They think they’re deploying microservices, resolving package dependencies, routing network traffic, or modeling social connections. But the underlying structure in all of these is a graph, and the algorithms that make those systems work — Dijkstra’s, topological sort, BFS, DFS — are graph algorithms.

Once I started seeing graphs everywhere, I started solving systems problems better. Let me show you the representation, the key algorithms, and the production contexts where this thinking pays off.

Lesson 7: Heaps and Priority Queues — Scheduling, top-K, and rate limiters

Tue, 09 Jul 2024 00:00:00 +0000

Every time your operating system picks the next process to run, it’s using a heap. Every time Kubernetes re-schedules a pod, it’s using a priority queue. Every time you’ve written a “get top 10 most frequent items from a billion-row stream,” the efficient solution involves a heap. These are workhorses of systems programming that look simple on paper and have genuinely tricky implementation details.

The heap is also one of my favorite data structures to explain because it demonstrates a beautiful property: you can implement a tree efficiently inside an array, using only arithmetic to find parent and child nodes.

Lesson 6: B-Trees and B+ Trees — How every database index actually works

Wed, 26 Jun 2024 00:00:00 +0000

Every time PostgreSQL, MySQL, SQLite, or MongoDB uses an index, it’s almost certainly a B-tree or B+ tree underneath. Not a binary search tree — a B-tree. The difference matters more than most engineers realize, and it comes down to one thing: disk read costs.

I’ve seen engineers add indexes blindly to fix slow queries without understanding what an index actually is. When you understand B-trees, you understand why some indexes help more than others, why certain query patterns can’t use indexes, and why index-heavy tables slow down on writes.

Lesson 5: Trees and BSTs — Why your database is a tree

Thu, 13 Jun 2024 00:00:00 +0000

When you run SELECT * FROM orders WHERE user_id = 42, your database doesn’t scan every row. It walks a tree. Understanding why databases chose trees over hash maps — and which kind of tree, and why — is one of those “oh, everything makes sense now” moments that changes how you design systems.

Let me start with binary search trees, get honest about their weaknesses, and set up the foundation for B-trees in the next lesson.

Lesson 4: Stacks and Queues — The structures hiding in every system

Tue, 28 May 2024 00:00:00 +0000

Every time you make a function call, your program uses a stack. Every HTTP request in a web server sits in a queue. Every undo operation in your IDE is a stack. These structures are so fundamental they’re baked into the hardware itself — the CPU has dedicated stack instructions.

Yet I consistently see engineers reach for generic slices or channels when a properly implemented stack or queue would be both clearer and faster. Let me show you what these structures actually are, why they’re the shape they are, and where they show up in the systems you work on every day.

Lesson 3: Hash Maps — O(1) with asterisks

Wed, 15 May 2024 00:00:00 +0000

Hash maps are the workhorse of production software. Nearly every caching layer, session store, deduplication system, and configuration lookup you’ve ever written relies on one. They’re fast, they’re flexible, and they’re genuinely O(1) — with some asterisks that matter enormously in production.

I want to walk through how they actually work, because the “O(1) lookup” claim hides a lot of complexity that shows up in the worst possible moments: under load, with adversarial input, or when your hash function is subtly wrong.

Lesson 2: Linked Lists — Almost never the right choice

Sun, 28 Apr 2024 00:00:00 +0000

Linked lists are the most over-taught data structure in computer science and the most under-used structure in production systems. I’ve reviewed hundreds of pull requests across distributed systems codebases, and I can count on one hand the times a linked list was genuinely the right call.

That said, understanding why linked lists are usually wrong teaches you something profound about how computers actually work. And there are a handful of situations where they’re exactly right — and when those situations come up, you need to recognize them fast.

Lesson 1: Arrays and Memory Layout — Cache lines decide your performance

Mon, 15 Apr 2024 00:00:00 +0000

I spent two years writing Go services before I genuinely understood why iterating over a two-dimensional slice in the wrong order could tank my throughput by 5x. It wasn’t a bug. It wasn’t a bad algorithm. It was cache lines.

Arrays are the first data structure everyone learns and the last one most engineers actually understand. This is my attempt to fix that — not with theory, but with the reasoning that makes you a better systems engineer.