ddia-principleslisted

Designing Data-Intensive Applications (DDIA) distilled reference guide by Martin Kleppmann. MUST be loaded when: designing database schemas, choosing storage engines, implementing replication or partitioning, handling distributed transactions, building batch/stream processing pipelines, choosing consistency models, implementing consensus, designing data flow architectures, evaluating trade-offs between availability and consistency, encoding/serialization decisions, data modeling (relational vs document vs graph), building fault-tolerant systems, or any system design and architecture discussion involving data-intensive applications. Trigger on: database design, replication, partitioning, sharding, transactions, isolation levels, consistency, consensus, CAP theorem, batch processing, stream processing, MapReduce, Kafka, event sourcing, CDC, OLTP, OLAP, B-tree, LSM-tree, data warehouse, schema evolution, encoding formats, distributed systems, fault tolerance, leader election, quorum.
satbirbhbc-ux/ai-coding-principles · ★ 1 · AI & Automation · score 74

Install: claude install-skill satbirbhbc-ux/ai-coding-principles

# Designing Data-Intensive Applications — Distilled Guide > Source: Martin Kleppmann, *Designing Data-Intensive Applications* > Central thesis: **Data is the core challenge of modern applications — not compute.** --- ## Part I: Foundations of Data Systems ### Chapter 1: Reliability, Scalability, Maintainability #### Three Pillars | Pillar | Definition | Key Metric | |--------|-----------|------------| | **Reliability** | System works correctly even when faults occur | Fault ≠ Failure; tolerate faults, prevent failures | | **Scalability** | System handles load growth gracefully | Measure with percentiles: p50, p95, p99, p999 | | **Maintainability** | System is easy to operate, understand, evolve | Operability + Simplicity + Evolvability | #### Fault Categories - **Hardware**: Random, independent (disk, RAM, power). Mitigate with redundancy (RAID, dual power). - **Software**: Systematic bugs affecting all nodes simultaneously (leap-second bug). Mitigate with process isolation, monitoring, chaos engineering. - **Human**: #1 cause of outages (config errors). Mitigate with good abstractions, sandboxes, canary deployments, fast rollback. #### Scalability Patterns - **Vertical (scale-up)**: Bigger machine. Simple but has ceiling. - **Horizontal (scale-out)**: More machines (shared-nothing). Complex but unlimited. - **Elastic**: Auto-scale on load detection. Good for unpredictable workloads. **Twitter fan-out case study**: 4.6k writes/s but 300k reads/s. Solution: pre-comput