Designing Data-Intensive Applications Skill
Reference for distributed systems and data architecture concepts from Martin Kleppmann's "Designing Data-Intensive Applications."
Activation Triggers
Use this skill when discussing:
- Database selection and data modeling
- Replication and high availability
- Partitioning/sharding strategies
- Distributed transactions
- Consistency models and guarantees
- Stream vs batch processing
- Event sourcing and CQRS
Quick Reference
Data Models
| Model |
Best For |
Trade-offs |
| Relational |
Complex queries, joins, ACID |
Schema rigidity, scaling writes |
| Document |
Hierarchical data, flexibility |
Poor joins, denormalization |
| Graph |
Highly connected data |
Specialized queries, complexity |
| Wide-Column |
Time series, analytics |
Limited query patterns |
Storage Engines
| Engine |
Optimized For |
Examples |
| B-Tree |
Read-heavy, random access |
PostgreSQL, MySQL |
| LSM-Tree |
Write-heavy, sequential |
Cassandra, RocksDB, LevelDB |
| Column Store |
Analytics, aggregations |
ClickHouse, Parquet |
Replication Strategies
| Strategy |
Consistency |
Availability |
Use Case |
| Single Leader |
Strong |
Medium |
Traditional RDBMS |
| Multi-Leader |
Eventual |
High |
Multi-datacenter |
| Leaderless |
Eventual |
Highest |
High availability |
Partitioning Strategies
| Strategy |
Description |
Pros |
Cons |
| Range |
Partition by key ranges |
Efficient range queries |
Hot spots |
| Hash |
Partition by hash of key |
Even distribution |
No range queries |
| Composite |
Combine range + hash |
Balanced |
Complexity |
Consistency Models
| Model |
Guarantee |
Performance |
| Linearizable |
Strongest (appears sequential) |
Slowest |
| Sequential |
Operations ordered per client |
Medium |
| Causal |
Cause-effect preserved |
Good |
| Eventual |
Will converge eventually |
Fastest |
Transaction Isolation Levels
| Level |
Dirty Read |
Non-Repeatable |
Phantom |
| Read Uncommitted |
✗ |
✗ |
✗ |
| Read Committed |
✓ |
✗ |
✗ |
| Repeatable Read |
✓ |
✓ |
✗ |
| Serializable |
✓ |
✓ |
✓ |
CAP Theorem
"In the presence of a network partition, choose Consistency OR Availability."
| Choice |
Behavior |
Examples |
| CP |
Reject requests if can't guarantee consistency |
ZooKeeper, HBase |
| AP |
Accept requests, allow inconsistency |
Cassandra, DynamoDB |
Batch vs Stream Processing
| Aspect |
Batch |
Stream |
| Latency |
High (hours/days) |
Low (seconds/minutes) |
| Data |
Bounded, complete |
Unbounded, continuous |
| Processing |
MapReduce, Spark |
Kafka, Flink, Storm |
| Use Case |
Analytics, ETL |
Real-time alerts, dashboards |
Directory Structure
ddia/
├── SKILL.md
├── data-models/
│ ├── relational.md
│ ├── document.md
│ └── graph.md
├── storage/
│ ├── b-trees.md
│ ├── lsm-trees.md
│ └── column-storage.md
├── replication/
│ ├── leader-follower.md
│ ├── multi-leader.md
│ └── leaderless.md
├── partitioning/
│ ├── strategies.md
│ └── rebalancing.md
├── transactions/
│ ├── acid.md
│ ├── isolation-levels.md
│ └── distributed-transactions.md
├── consistency/
│ ├── models.md
│ └── linearizability.md
├── consensus/
│ └── algorithms.md
└── processing/
├── batch.md
├── stream.md
└── event-sourcing.md
Usage Examples
Choosing a Database
Question: "Should I use PostgreSQL or MongoDB?"
Consider:
- Data relationships → See data-models/
- Query patterns → See storage/
- Scale requirements → See partitioning/
- Consistency needs → See consistency/
Designing for Scale
Question: "How do I handle millions of users?"
Consider:
- Read scaling → See replication/leader-follower.md
- Write scaling → See partitioning/strategies.md
- Geographic distribution → See replication/multi-leader.md
Handling Failures
Question: "What happens when a node fails?"
Consider:
- Data durability → See replication/
- Consistency trade-offs → See consistency/models.md
- Recovery → See consensus/algorithms.md
Based on concepts from "Designing Data-Intensive Applications" by Martin Kleppmann.
1---2name: ddia3description: Designing Data-Intensive Applications Skill4---5# Designing Data-Intensive Applications Skill67Reference for distributed systems and data architecture concepts from Martin Kleppmann's "Designing Data-Intensive Applications."89## Activation Triggers1011Use this skill when discussing:12- Database selection and data modeling13- Replication and high availability14- Partitioning/sharding strategies15- Distributed transactions16- Consistency models and guarantees17- Stream vs batch processing18- Event sourcing and CQRS1920## Quick Reference2122### Data Models2324| Model | Best For | Trade-offs |25|-------|----------|------------|26| Relational | Complex queries, joins, ACID | Schema rigidity, scaling writes |27| Document | Hierarchical data, flexibility | Poor joins, denormalization |28| Graph | Highly connected data | Specialized queries, complexity |29| Wide-Column | Time series, analytics | Limited query patterns |3031### Storage Engines3233| Engine | Optimized For | Examples |34|--------|---------------|----------|35| B-Tree | Read-heavy, random access | PostgreSQL, MySQL |36| LSM-Tree | Write-heavy, sequential | Cassandra, RocksDB, LevelDB |37| Column Store | Analytics, aggregations | ClickHouse, Parquet |3839### Replication Strategies4041| Strategy | Consistency | Availability | Use Case |42|----------|-------------|--------------|----------|43| Single Leader | Strong | Medium | Traditional RDBMS |44| Multi-Leader | Eventual | High | Multi-datacenter |45| Leaderless | Eventual | Highest | High availability |4647### Partitioning Strategies4849| Strategy | Description | Pros | Cons |50|----------|-------------|------|------|51| Range | Partition by key ranges | Efficient range queries | Hot spots |52| Hash | Partition by hash of key | Even distribution | No range queries |53| Composite | Combine range + hash | Balanced | Complexity |5455### Consistency Models5657| Model | Guarantee | Performance |58|-------|-----------|-------------|59| Linearizable | Strongest (appears sequential) | Slowest |60| Sequential | Operations ordered per client | Medium |61| Causal | Cause-effect preserved | Good |62| Eventual | Will converge eventually | Fastest |6364### Transaction Isolation Levels6566| Level | Dirty Read | Non-Repeatable | Phantom |67|-------|------------|----------------|---------|68| Read Uncommitted | ✗ | ✗ | ✗ |69| Read Committed | ✓ | ✗ | ✗ |70| Repeatable Read | ✓ | ✓ | ✗ |71| Serializable | ✓ | ✓ | ✓ |7273### CAP Theorem7475> "In the presence of a network partition, choose Consistency OR Availability."7677| Choice | Behavior | Examples |78|--------|----------|----------|79| CP | Reject requests if can't guarantee consistency | ZooKeeper, HBase |80| AP | Accept requests, allow inconsistency | Cassandra, DynamoDB |8182### Batch vs Stream Processing8384| Aspect | Batch | Stream |85|--------|-------|--------|86| Latency | High (hours/days) | Low (seconds/minutes) |87| Data | Bounded, complete | Unbounded, continuous |88| Processing | MapReduce, Spark | Kafka, Flink, Storm |89| Use Case | Analytics, ETL | Real-time alerts, dashboards |9091## Directory Structure9293```94ddia/95├── SKILL.md96├── data-models/97│ ├── relational.md98│ ├── document.md99│ └── graph.md100├── storage/101│ ├── b-trees.md102│ ├── lsm-trees.md103│ └── column-storage.md104├── replication/105│ ├── leader-follower.md106│ ├── multi-leader.md107│ └── leaderless.md108├── partitioning/109│ ├── strategies.md110│ └── rebalancing.md111├── transactions/112│ ├── acid.md113│ ├── isolation-levels.md114│ └── distributed-transactions.md115├── consistency/116│ ├── models.md117│ └── linearizability.md118├── consensus/119│ └── algorithms.md120└── processing/121 ├── batch.md122 ├── stream.md123 └── event-sourcing.md124```125126## Usage Examples127128### Choosing a Database129130```131Question: "Should I use PostgreSQL or MongoDB?"132133Consider:134- Data relationships → See data-models/135- Query patterns → See storage/136- Scale requirements → See partitioning/137- Consistency needs → See consistency/138```139140### Designing for Scale141142```143Question: "How do I handle millions of users?"144145Consider:146- Read scaling → See replication/leader-follower.md147- Write scaling → See partitioning/strategies.md148- Geographic distribution → See replication/multi-leader.md149```150151### Handling Failures152153```154Question: "What happens when a node fails?"155156Consider:157- Data durability → See replication/158- Consistency trade-offs → See consistency/models.md159- Recovery → See consensus/algorithms.md160```161162---163164*Based on concepts from "Designing Data-Intensive Applications" by Martin Kleppmann.*