Data-Intensive Apps
Designing reliable, scalable data systems
Design reliable, scalable, and maintainable data systems using Martin Kleppmann's comprehensive guide. This skill equips your AI agent with deep knowledge of storage engines, replication, partitioning, consistency models, and stream processing for building data-intensive applications.
npx skills add wondelai/skills/ddia-systems --global 
Designing Data-Intensive Applications Martin Kleppmann View on Amazon
02 What it is
What is the Data-Intensive Apps skill?
Data-Intensive Apps carries Martin Kleppmann’s Designing Data-Intensive Applications into your AI coding agent as a free, loadable skill. It supplies the internals behind storage engines, replication, partitioning and isolation levels, so when the agent proposes a database, a sharding key or a consistency model it can name the failure mode it is accepting.
03 Key concepts
Five principles your agent applies.
Drawn from Designing Data-Intensive Applications — not advice it repeats back to you, but decisions it makes while it works.
04 Fit
When to use it, and
when not to.
four symptoms it fixes, and four it doesn't.
Reach for it when
Two users bought the last item in stock and the code looked correct, because the default isolation level is not serializable.
A user updates their profile, reloads, and is served the old value from a read replica.
You are choosing between Postgres, a document store and a key-value store, and familiarity is the only argument on the table.
Your partition key routes most traffic to one shard, and rebalancing has become a production problem.
Reach for something else when
You need capacity numbers and a component sketch rather than storage-engine internals. System Design is the faster route.
The question is how the app copes when the database is slow rather than wrong. that is Release It!.
You are shaping domain objects and their invariants, not their persistence. Domain-Driven Design fits better.
The bottleneck is between the browser and your first byte. see High Perf Browser.
05 Prompts
Say it like this.
Name the skill at the end of a prompt and the agent applies the framework rather than a vibe. Or say nothing — it loads on its own when a task matches.
Recommend a storage engine and replication strategy for our write-heavy workload using ddia-systems skill
Design a data partitioning scheme that avoids hotspots using ddia-systems skill
Evaluate consistency trade-offs for our distributed checkout system using ddia-systems skill
Design a stream processing pipeline for real-time analytics using ddia-systems skill
06 About the author
07 Same stack
The stack it sits in.
Six Architecture & Systems skills. Most people run two: this one, and whichever fits the next problem.
All Architecture & Systems skills08 Questions
Before you install.
How do I install the Data-Intensive Apps skill?
Run npx skills add wondelai/skills/ddia-systems --global. It takes about 30 seconds and needs no account. The Data-Intensive Apps skill then works in Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw and Hermes Agent — anything that reads the open agentskills.io format — and your agent loads it on its own when a task calls for it. It is free and MIT-licensed, and the source is at https://github.com/wondelai/skills.
Which book is the Data-Intensive Apps skill based on?
It packages Designing Data-Intensive Applications by Martin Kleppmann — cambridge researcher, former LinkedIn engineer, definitive data systems author. The skill distils the book's method into instructions your agent follows while it works, covering storage engines, replication & partitioning and consistency & consensus. It sits in the Architecture & Systems part of the library.
How is this different from the System Design skill?
System Design works at the level of boxes and arrows — how many servers, which cache, where the queue goes — and gets you to a defensible design quickly. Data-Intensive Apps works inside the boxes: why an LSM-tree beats a B-tree under write-heavy load, what your replication topology does to read-your-writes, which anomalies snapshot isolation still permits. Size the system with Xu, then justify what is inside it with Kleppmann.
What does CAP actually tell me?
Much less than it is usually credited with. CAP says only that a system which must stay available to clients on both sides of a network partition cannot also be linearizable. It says nothing about latency, nothing about trade-offs while the network is healthy, and its consistency means linearizability specifically, not the C in ACID. The skill prefers the more useful framing: pick a consistency or isolation level per operation and know the anomalies it permits.
Is eventual consistency just “the data catches up”?
That is the guarantee, and it is a weak one: it promises only that if writes stop, replicas converge, with no bound on when. What matters is which anomalies you tolerate meanwhile. Reading your own stale write, watching a value move backwards on refresh, or seeing an effect before its cause are all permitted unless you add a stronger guarantee — read-your-writes, monotonic reads or consistent prefix reads. The skill names the one each read path needs.
Do I need a distributed system to get value from this?
No — a large share of the material is about a single node. Storage-engine trade-offs, index design, isolation levels and write skew all apply to one Postgres instance, which is where most teams’ real data bugs live. Where the skill can mislead is scope: it will happily discuss consensus, multi-leader replication and stream processing for a service with five hundred users. Ask it what you can skip, or size the system with System Design first.
09 Guides that use it
Put it to work.
Long-form playbooks where this skill does part of the job.
One skill, one command.
Install Data-Intensive Apps, or the whole stack.
npx skills add wondelai/skills/ddia-systems --global MIT licensed · Claude, Claude Code, Codex, Cursor, OpenClaw, Hermes · No account