DevelopmentSubsection
Architecture
Where to put the boundaries, and what each boundary costs. Four topics: the two shapes a system can take, the migration between them that most teams attempt at the wrong moment, and the contract that makes any boundary usable by somebody else. The recurring theme is that a boundary is not free — it buys independence and charges you in latency, debugging and operational surface.
What is inside
Every page in this group, with what each one covers.
- MonolithOne deployable, described as a deliberate choice rather than a starting condition — including how to keep it modular.ModularOne deploy
- MicroservicesWhat independent deployment actually requires, and the operational bill that arrives with it.BoundariesOps cost
- Monolith → MicroservicesThe strangler fig pattern, done in an order that keeps the system shippable at every step of the way.Strangler figIncremental
- API DesignThe contract as the product: versioning, errors that are actionable, pagination, and what breaks a consumer.ContractVersioning
Where to start
- Starting a new systemMonolith. Read it as an argument rather than a default — a modular monolith is a choice you should be able to defend.
- Considering a splitMicroservices for the bill, then the migration page for the order. Doing it in the wrong order is the usual failure.
- Someone else consumes itAPI design. The moment a second team depends on your interface, the contract is the product.
Elsewhere in the section
- DevelopmentSoftware development is the work of deciding where the boundaries in a system go, what runs on each side of them, and what moving one of those boundaries will cost once the code is live. This section covers 28 topics — architecture, the browser, five backend runtimes, four mobile platforms, language models and the databases underneath all of it. Every page turns on the constraint that actually separates the options, rather than on the API surface.
- BackendFive runtimes, described by the one thing that actually differs between them: how each handles concurrency. Not syntax, not ecosystem size, not benchmarks — the execution model, because that is what decides which problems a language makes easy and which it makes expensive. Read two of these side by side and most "which language should we use" arguments answer themselves.
- DatabasesWhere the state lives, and what each store guarantees about it. Three topics: how a relational engine actually answers a query, what a non-relational store trades away to scale, and how to design a schema that will still be true in three years. Modelling comes last on purpose — it is the one that determines whether the other two are easy or painful.
Found this useful?
Share it with someone who is working on the same problem.