Designing Distributed Systems, 2nd Edition Patterns and Paradigms for Scalable, Reliable Systems Using Kubernetes (Brendan Burns)（Z-Library）

【One-Line Pitch】 A pattern-language guide for building reliable distributed systems on Kubernetes, showing how small reusable container components and proven architectural patterns let teams ship scalable software without reinventing coordination, scaling, and failure handling. Best for application developers and systems architects who already know containers and want a shared vocabulary for designing distributed applications. 【Book Arc】 - **Opening (~0%–10%)**: Frames the problem — distributed systems are hard, and shared design patterns give teams a common language. Introduces the container/Kubernetes context and previews the pattern catalog (sidecar, adapter, ambassador, multinode, batch). - **Early (~10%–30%)**: Builds foundations: a brief history of software patterns (from Knuth's algorithms to object-oriented design patterns) and core distributed concepts — APIs/RPCs, message delivery semantics, relational integrity, and health checks (liveness vs. readiness). - **Middle (~30%–55%)**: Covers single-node, multi-container patterns. The sidecar pattern for modularity and reuse; the ambassador pattern for sharding, service brokering, and request splitting/experimentation; the adapter pattern for monitoring, logging, and health normalization. - **Late (~55%–85%)**: Moves to multinode serving and batch patterns — replicated load-balanced services, sharding, work queues, event-based processing, and coordinated workflows for large-scale data processing. - **Ending (~85%–100%)**: Addresses real-world robustness: common failure patterns (thundering herd, misleading absence of errors, versioning errors, the "second system" problem) and a closing reflection on where distributed design goes next. 【Key Takeaways】 - **Patterns are a shared language, not just recipes** (Early): The book's core argument is that naming recurring designs lets architects and developers describe systems precisely and learn from each other's experience. - **Containers make patterns composable** (Middle): Sidecar, ambassador, and adapter patterns split an application into cooperating containers on one machine, each with a clean API, enabling reuse and separation of concerns. - **Sidecars extend without modifying the app** (Middle): Useful for legacy applications and cross-cutting concerns like introspection (e.g., a shared topz-style resource view), but they trade off some tailoring versus in-process libraries. - **Ambassadors encapsulate hard infrastructure logic** (Middle): Sharding, service discovery/brokering, and request splitting can be hidden behind a proxy container so application code stays simple and portable. - **Adapters normalize heterogeneous systems** (Middle): Monitoring, logging, and health checks can be unified across diverse applications by adapting their outputs to a common interface. - **Health has two meanings** (Early): Liveness (is it running?) and readiness (is it ready for traffic?) drive restarts, load-balancer membership, and rollout decisions — conflating them causes operational mistakes. - **Delivery semantics and relational integrity are design trade-offs** (Early): Exactly-once delivery is impractical; systems should handle at-most-once or at-least-once. Strong relational integrity across stores costs distributed transactions and parallelism, echoing the SQL vs. NoSQL split. - **Failure patterns are predictable and worth studying** (Ending): Thundering herds, silent errors, versioning mistakes, and the "second system" problem recur; recognizing them early improves reliability. 【Reading Tips】 - Skim the history-of-patterns section if you already know design patterns; slow down on the concepts chapter (APIs/RPCs, delivery semantics, health checks) since later patterns assume it. - Treat the hands-on examples (sharded Redis, 10% experiments, Prometheus monitoring, fluentd logging) as templates — adapt the YAML and container APIs rather than copying verbatim. - Deep-read the failure-patterns chapter near the end; it is the most practical checklist for reviewing your own system design. - Keep the pattern names (sidecar, ambassador, adapter) as a vocabulary you can use in design reviews and architecture docs. 【Coverage Limits】 The excerpts cover the book's framing, foundational concepts, single-node patterns, and failure patterns, but the multinode serving/batch chapters and the new AI inference and AI training chapters are only referenced, not detailed. Specific implementation depth for those later chapters is not covered here.