Reliable, Scalable, Maintainable

Kleppmann spends the first chapter defining three words before touching a database. It reads like throat clearing and is not.

Reliability

Defined as continuing to work correctly when things go wrong, which makes fault tolerance a design target rather than a quality. The distinction between a fault (one component misbehaving) and a failure (the system stops serving) is the one that does real work later in the book.

The uncomfortable claim is that hardware faults are the easy case. Software faults are correlated across nodes, so redundancy does not help, and humans are the largest single cause of outages in the studies cited.

Scalability

Not a property a system has. It is a question: if load grows in this specific way, what happens? That forces you to name the load parameter first, which is where most scaling arguments quietly cheat.

The percentile argument here is the practical takeaway. Averages hide the experience of your worst served users, and those are disproportionately your heaviest users, who have the most data.

Maintainability

Three sub-goals: operability, simplicity, evolvability. The weakest section of the chapter, and the one whose ideas I use most often anyway, because most systems die of accumulated complexity rather than of any single failure.

Where I would push back

The chapter treats these three as roughly co-equal. In practice they trade against each other hard, and the book does not give you a way to price the trade. That comes later, implicitly, and never gets stated as a method.