Books Deep-Read

Ch 1Reliable, Scalable, Maintainable — set three yardsticks and make "is this system good?" measurable with load parameters and response-time percentilesKleppmann · 2017 Ch 2Data Models & Query Languages — what relational, document and graph are each good at, and why declarative beats imperativeKleppmann · 2017 Ch 3Storage & Retrieval — how databases store and find data: LSM-trees vs B-trees, row-oriented OLTP vs columnar analyticsKleppmann · 2017 Ch 4Encoding & Evolution — how data is serialized and how schemas evolve with forward/backward compatibility, no downtimeKleppmann · 2017 Ch 5Replication — one dataset on many machines: single-leader, multi-leader, leaderless, and the pitfalls of replication lagKleppmann · 2017 Ch 6Partitioning — splitting a dataset too big for one node: by key range or by hash, hotspots and rebalancingKleppmann · 2017 Ch 7Transactions — what ACID actually guarantees, which anomalies weak isolation lets through, and why write skew is the trap to rememberKleppmann · 2017 Ch 8The Trouble with Distributed Systems — partial failures, unreliable clocks, network and process pausesKleppmann · 2017 Ch 9Consistency & Consensus — linearizability, total-order broadcast and consensus, what to really know after CAPKleppmann · 2017 Ch 10Batch Processing — MapReduce's tally-then-total, one distributed sort turning huge immutable input into derived results, recompute on failureKleppmann · 2017 Ch 11Stream Processing — process a never-ending event stream one at a time on a replayable log (Kafka); stream-table duality turns the database inside out, with time and watermarks as the hard partKleppmann · 2017 Ch 12The Future of Data Systems — unbundle the database and reassemble it around one ordered event log; correctness comes end-to-end, not from the layers belowKleppmann · 2017 Ch 1The Problem of Delivering Software — manual deploys and release-day hell; turn releasing into a repeatable pipelineHumble & Farley · 2010 Ch 2Configuration Management — everything under version control, one artifact for every environment, no manual changes to machinesHumble & Farley · 2010 Ch 3Continuous Integration — merge to trunk every day and stop the line when it goes red; CI is a practice, not a toolHumble & Farley · 2010 Ch 4Implementing a Testing Strategy — four quadrants: automate what repeats, leave curiosity to peopleHumble & Farley · 2010 Ch 5Anatomy of the Deployment Pipeline — one automated road from commit to production: build once, stop the line when redHumble & Farley · 2010 Ch 7The Commit Stage — a trustworthy red or green within ten minutes; that budget governs people, not machinesHumble & Farley · 2010 Ch 8Automated Acceptance Testing — separate what to verify from how to click it, or the suite becomes unaffordableHumble & Farley · 2010 Ch 10Deploying and Releasing Applications — blue-green and canary make going live revocable; the wall is never the code, it's the dataHumble & Farley · 2010 Ch 11Managing Infrastructure and Environments — only automation builds or changes a machine, from definitions in version control; edit one by hand and it is unreproducibleHumble & Farley · 2010 Ch 12Managing Data — code swaps back to the previous version, data does not; non-destructive migrations and a compatibility window make releases revocable againHumble & Farley · 2010 Ch 13Components and Dependencies — you split to get the build back under ten minutes; the price is losing one-commit-one-verification, bought back with pinned versions and an integration pipelineHumble & Farley · 2010 Ch 1Introduction — ask a software engineer to design an ops team, then pin it down with a 50% engineering floor and an error budgetGoogle · 2016 Ch 3Embracing Risk — 100% is the wrong target; treat 1 minus the SLO as a budget you spend, ship while it lasts, freeze when it's goneGoogle · 2016 Ch 4Service Level Objectives — pick the right thing to measure before arguing about nines; a good SLO names its window and measurement pointGoogle · 2016 Ch 5Eliminating Toil — the test isn't whether you hate the work but whether it grows linearly; 50% is a ceiling, not a targetGoogle · 2016 Ch 6Monitoring Distributed Systems — the four golden signals as a minimum sufficient set; never page for work a script could doGoogle · 2016 Ch 8Release Engineering — shipping fast is the result; reproducibility is the foundation, and config needs its own version tooGoogle · 2016 Ch 9Simplicity — reliability is capped by what you can still understand; code is a liability, and the best change is a negative oneGoogle · 2016 Ch 12Effective Troubleshooting — a craft, not a gift: stop the bleeding first, cut from the middle, then ask where the effort goesGoogle · 2016 Ch 15Postmortem Culture — chase the conditions, not the person; the output isn't a document, it's action items tracked to closedGoogle · 2016 Ch 21Handling Overload — stop measuring capacity in QPS; take on less on purpose and output holds at the ceilingGoogle · 2016 Ch 22Addressing Cascading Failures — failure breeds; removing the trigger won't bring the system back, you have to cut the loopGoogle · 2016 Ch 23Managing Critical State — heartbeat-and-timeout doesn't avoid consensus, it implements it wrong; take this one off the shelfGoogle · 2016 Ch 25Data Processing Pipelines — the enemy isn't data volume, it's the periodic schedule itself: idle troughs, herd peaks, and a middle you can't monitorGoogle · 2016 Ch 26Data Integrity — replicas don't protect your data, they just sync the bad delete faster; three lines of defense doGoogle · 2016 Ch 1Accelerate — speed and stability aren't a trade-off; improve by finding your weakest capability, not by climbing maturity levelsForsgren et al. · 2018 Ch 2Measuring Performance — stop counting effort; count four outcomes that constrain each other so no side can be won by wrecking the otherForsgren et al. · 2018 Ch 3Measuring and Changing Culture — stop asking what the culture is like; watch whether bad news reaches the person who needs itForsgren et al. · 2018 Ch 4Technical Practices — continuous delivery isn't a pipeline you buy; it's keeping trunk shippable, and who writes the tests separates teams more than whether tests existForsgren et al. · 2018 Ch 5Architecture — stop arguing monolith vs microservices; ask two questions: can you test alone, can you ship aloneForsgren et al. · 2018 Ch 6Integrating Infosec — security isn't a door before release; it's paving the road so the right thing is easier than going aroundForsgren et al. · 2018 Ch 9Making Work Sustainable — don't ask if the team is tired; ask what day and hour they last deployed. Burnout is an output of the environmentForsgren et al. · 2018