Track 02 — Infrastructure Systems
This track follows the runtime: everything that has to keep information available, fast, and recoverable once Track 01's schemas and models are actually deployed and taking load. Ten articles, from the layers outside your application binary to the closing argument that resilience is a design-time constraint, not a backlog item.
The split exists for the same reason a physical library separates fiction from reference — not because the two never inform each other, but because a reader looking for "why is my socket pool exhausted" shouldn't have to wade through canonical business models to find it, and vice versa. The tracks were split by altitude of concern — runtime survival on this shelf, data semantics on the other — not by chronology.
What's on This Shelf
• Articles 2–12 (even): the survival arc — why application code isn't the system, containing dependency failure, the modern shape of a memory leak, why session state has a cost, socket exhaustion, and the reverse proxy as trust boundary.
• Articles 14, 16, 18 (even): the pressure arc — teaching a gateway to say no before an unbounded queue does it instead, why caches are harder than the databases they front, and designing for recovery instead of only prevention.
• Article 20: the synthesis — every article above, plus Track 01's own synthesis, read as one closing argument about when stability has to be designed in.
Start at Your Application Code Is Not the System, or jump to the finale directly at Stability Is an Architectural Core Constraint, Not a Post-Script Feature if you've already read the rest.