Skip to content
Past Localhost
IntroductionLesson 1 of 2

How to use this guide

Who it's for, how the lessons are organized and the reference project used in the examples.

Goal
Know what to expect from the guide, what order to read it in and how to turn each lesson into a real change in your project.

Who it’s for

Section titled “Who it’s for”

You already write code and you’ve shipped something, maybe with a lot of help from AI. The app works. But when someone asks “what happens if two users do this at the same time?” or “how would you roll this back?”, the answer is an awkward silence.

This guide covers those gaps. It assumes you can already program and it doesn’t depend on any framework. Its subject is the engineering reasoning that keeps a system running once real users and real data show up and things start to fail.

The tracks

Section titled “The tracks”
Track Parts When to read
Core 1 to 7 and 10 In order. Everything else builds on it.
Product 8 (business) and 9 (AI) When your system charges money, measures growth or uses LLMs.
Mobile 11 Only if you’re shipping a native app.

The order of the Core matters. Part 1 changes how you look at a system. The parts after it apply that view to each layer: code, data, network, security, infrastructure and architecture.

flowchart TB
  P1[1 · Engineering mindset] --> P2[2 · Tools and groundwork] --> P3[3 · Data] --> P4[4 · Networks and APIs]
  P4 --> P5[5 · Security and reliability] --> P6[6 · Delivery] --> P7[7 · Architecture and growth] --> P10[10 · Operations]
  P7 -.-> P8[8 · Money and metrics]
  P7 -.-> P9[9 · AI features]
  P10 -.-> P11[11 · Mobile apps]

How each lesson is organized

Section titled “How each lesson is organized”

Every page follows the same format, so you know where to look:

  1. Goal: what you’ll be able to do after reading.
  2. The problem: a concrete production scenario.
  3. The concept: the minimum explanation, usually with a diagram.
  4. In practice: code, configuration or commands.
  5. Pitfalls: including what AI tends to get wrong.

Each module ends with a summary, review questions and, when there’s a good example, a postmortem: a real public incident, its cause and the lesson from the module that would have prevented it.

The reference project: Linkr

Section titled “The reference project: Linkr”

So the examples connect to each other, almost all of them use the same fictional system:

Linkr is a link shortener with analytics. Users create short links, see clicks on a dashboard and can subscribe to a Pro plan (paid through Stripe) that unlocks custom domains and a public API.

It’s small, but it has nearly every problem a real system has:

  • Hot reads: redirecting linkr.app/abc has to be very fast (caching, indexes).
  • High-volume writes: every click produces an event (queues, async processing).
  • Money: subscriptions and webhooks (idempotency, consistency).
  • Public API: contracts, versioning, rate limiting.
  • Abuse: malicious links, scraping, fake accounts (security).

The example stack is TypeScript + Node.js + PostgreSQL, with Redis, Docker and GitHub Actions when the topic calls for them. The concepts apply to any stack; only the syntax changes.

How to study

Section titled “How to study”
  • Keep one of your own projects open alongside and look for each lesson’s problem in it. Reading without applying doesn’t get you far.
  • Don’t skip Part 1 because it looks “theoretical”. It’s short and it changes how you read everything after it.
  • When something breaks, use the symptom map. It points straight to the right module.
  • Read the code carefully. The examples are short on purpose, and the comments explain why the code does something.
  • At the end of each page, tick Mark as read. The home page then gets a Continue reading button that opens the next page you haven’t read. Your progress is saved only in this browser.

Go deeper

Materials in English unless noted.

Written by About this guide