DevelopmentSubsection
Databases
Where 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.
What is inside
Every page in this group, with what each one covers.
- SQLSixteen surprises — wrong rows, slow queries, lost updates — the planner, isolation levels, the lock queue, and five cases.PlannerIndexes
- NoSQLSixteen things a relational database did for you, the partition key, quorums and lost writes, and five cases.PartitionsAccess patterns
- Data ModelingSixteen questions for every table — keys, normal forms, types and NULL, history and two clocks, star schemas, five cases.Normal formsHistory
Where to start
- Queries are slowSQL, and read the planner section first — almost every slow query is a plan you did not expect.
- Choosing a storeNoSQL, for the partitioning question. If you cannot name your access patterns yet, that is the answer.
- Designing a schemaData modeling, starting with the sixteen questions — each is far cheaper to answer before the first table exists.
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 30 topics — architecture, the browser, seven backend languages, 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.
- BackendSeven languages and runtimes, described by the one thing that actually differs between them: the execution model — how each one handles concurrency, memory and failure. Not syntax, not ecosystem size, not benchmarks, because the execution model is what decides which problems a language makes easy and which it makes expensive. Five are general-purpose server runtimes. Rust frees memory without a garbage collector, at a point the compiler checks. Solidity runs on a public machine where every call is open to anyone and the code cannot change. Read two of these side by side and most "which language should we use" arguments answer themselves.
- ArchitectureWhere 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.
Found this useful?
Share it with someone who is working on the same problem.