Three engineers sit in a post-mortem. A cache stampede took down the recommendation service for four hours. The first engineer says the cache TTL was too short. The second says the database could not handle the fallback load. The third says the retry logic amplified the problem. They are all correct. They are describing the same failure at different layers of the stack. None of them can see the whole picture because they each work in one layer and cannot see the others.
The Knowledge Stack is a map of those layers. It shows you where each pattern lives and why the same patterns appear everywhere — which is the only explanation for why three engineers can look at one incident and see three different problems. B-trees are a familiar structure. PostgreSQL indexes are a familiar feature. The connection between them — “B-tree” is “the thing running inside every database index you have ever used” — may not be explicit. That connection, once made, makes both facts stickier — and more useful.
The Knowledge Stack is the map of those connections. It shows the seven layers of the field, from mathematical foundations to product strategy, and the twelve threads that run vertically through all of them.
Each layer depends on the one below it. Infrastructure patterns are implementations of algorithms. System designs are compositions of infrastructure patterns. Code architecture governs how system designs are expressed in code. Leadership determines which systems get built and how. Product strategy determines what value those systems deliver.
Each layer depends on the one below. More importantly, the same patterns appear at every layer. A queue at the mathematical level is FIFO ordering. At the algorithm level it enables BFS traversal. At the infrastructure level it is a Kafka topic. At the system level it is the fan-out mechanism in a news feed. At the code level it is an event emitter. At the leadership level it is the async handoff between teams. The word “queue” means something at every layer — and understanding all of them deepens your understanding of each.
Layer 1 — Mathematics. Not because software engineers need to be mathematicians. Because mathematical structures are the most precise way to express patterns that appear in computing. Understanding that a hash function is a surjection from a large domain to a small codomain reveals not just what hashing does but why collisions are unavoidable and why the distribution of the hash function matters.
Layer 2 — Algorithm Engineering. The translation layer between theory and production. Most developers have learned algorithms in isolation — sorting algorithms, graph algorithms, dynamic programming — without seeing where they run in real systems. This layer makes the connections explicit.
Layer 3 — Infrastructure Patterns. The building blocks that every production system uses. Caches, queues, databases, load balancers, consensus protocols. These are not individual technologies but patterns that technologies implement. Redis, Kafka, PostgreSQL, Nginx — all of them are implementations of patterns that have existed for decades.
Layer 4 — System Design. Where all the infrastructure patterns combine into complete systems. A payment processor, a news feed, a video streaming platform — each is a specific arrangement of infrastructure patterns, selected to meet specific requirements.
Layer 5 — Code Architecture. The layer between algorithms and infrastructure that governs how code is structured. Coupling, cohesion, hexagonal architecture, testing strategy. The concerns at this layer are different from infrastructure — they are about how code is organised, not how systems are deployed.
Layer 6 — Leadership. The layer where technical decisions intersect with organisational ones. Conway’s Law operates here. Technical debt becomes a business risk here. Architecture reviews, technology roadmaps, and hiring decisions all live at this layer.
Layer 7 — Product Strategy. The layer where systems create user value. Network effects, growth loops, platform design, AI product architecture. The concerns here are product and business, but they are grounded in technical reality — you cannot design a platform without understanding what the technical constraints on extensibility actually are.
Twelve patterns run through all seven layers. They are introduced fully in Chapter 3. Here they are by name, to give you a first orientation:
These threads are the vertical axis of the series. Every chapter in every book activates one or more of them. When you read a chapter and see “T5” in the thread reference, you can trace that thread backwards to its mathematical root and forward to its product manifestation.
You already use most of these patterns. You have probably:
The difference between using a pattern and understanding it is the difference between fixing this bug and preventing the next one. The Knowledge Stack gives you the vocabulary to see what you are already doing, name it, and apply it deliberately.