Layering and Abstraction
The pattern: solve a complex problem by stacking layers, where each layer hides the layer below’s complexity and exposes a smaller interface upward. Each layer’s interface is its contract. As long as the contract holds, the layer below can change without breaking the layer above. The whole industry runs on this — TCP/IP, libc on top of the kernel, Kubernetes on top of containers, Iceberg metadata on top of object storage.
The trade-off: abstraction clarity vs. leaky details. Good layering makes higher levels simpler to reason about. But abstractions leak — TCP-over-bad-WiFi reveals the network layer; a slow query reveals the storage engine; a kernel bug reveals what your “innocent” syscall actually does. Senior engineers know when to trust the abstraction and when to peel it back. Junior engineers either trust too much (don’t understand what’s underneath) or too little (reimplement the layer below “just in case”).
[Deepen across Year 1 — every phase exercises this pattern.]
Related patterns
- mediation — mediators define the contract at each layer boundary.
- privilege-separation — privilege boundaries usually coincide with layer boundaries.
- resource-virtualization — virtualization is the canonical abstraction over hardware.
- state-vs-computation — separating storage from compute is layering applied to data systems.
- declarative-vs-imperative-infrastructure — declarative = a higher layer exposing intent over imperative steps.
- platform-as-product — the platform is a layer with a contract; treat it that way.
- First touched: Year 1 Phase 1: OS Foundations.
- Reinforced in: Year 1 Phase 2: Networking, Year 1 Phase 6: Containers, Year 3 Phase 15: Lakehouse.