From system-design
Knowledge base from "System Design Interview - An Insider's Guide (Vol 1 & 2)" by Alex Xu. Use when applying Alex Xu's frameworks for the 4-step interview method, back-of-envelope estimation, scaling, consistency/CAP, sharding, caching, fanout, queues, or designing systems (rate limiter, KV store, news feed, chat, payment, etc.), studying the book, or referencing its concepts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/system-design:system-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- argument-hint: [topic, framework name, or chapter number e.g. ch11] -->
chapters/ch01-scaling.mdchapters/ch02-estimation.mdchapters/ch03-interview-framework.mdchapters/ch04-rate-limiter.mdchapters/ch05-consistent-hashing.mdchapters/ch06-key-value-store.mdchapters/ch07-unique-id-generator.mdchapters/ch08-url-shortener.mdchapters/ch09-web-crawler.mdchapters/ch10-notification-system.mdchapters/ch11-news-feed.mdchapters/ch12-chat-system.mdchapters/ch13-search-autocomplete.mdchapters/ch14-youtube.mdchapters/ch15-google-drive.mdchapters/ch16-proximity-service.mdchapters/ch17-nearby-friends.mdchapters/ch18-google-maps.mdchapters/ch19-message-queue.mdchapters/ch20-metrics-monitoring.mdAuthor: Alex Xu (Vol 2 with Sahn Lam) | Chapters: 28 | Generated: 2026-06-22
rate limiting, fanout, consistent hashing, exactly-once; I find and read the relevant chapterch11; I load that specific chapter fileWhen you ask about a topic not in Core Frameworks below, I read the relevant chapter file (Topic Index → chapter) before answering.
The 4-Step Interview Framework (Ch3) — the spine of every design.
Back-of-Envelope Estimation (Ch2). Drive the design with numbers. QPS = DAU × actions/user/day ÷ 86,400; peak ≈ 2× average. Memorize Jeff Dean latency numbers (memory 100ns, SSD 150µs, disk seek 10ms, intra-DC RTT 500µs, cross-region 150ms) and availability nines (99.9% = 8.8h/yr down, 99.99% = 52min/yr). Label units; round liberally; process > precision.
Scaling spine (Ch1). Stateless web tier → horizontal scale behind a load balancer. Master-slave DB replication for read scale. Cache read-heavy data (LRU). CDN for static. Shard when one DB isn't enough. Message queues to decouple + async. Multi-DC + GeoDNS for geo & failover.
CAP + Quorum (Ch6). Partition tolerance is mandatory → choose CP (consistency) or AP (availability). Tune with quorum: W + R > N ⇒ strong consistency (common N=3, W=R=2). Detect conflicts with vector clocks, sync replicas with Merkle trees, detect failure via gossip, survive failures with sloppy quorum + hinted handoff.
Consistent Hashing + Virtual Nodes (Ch5). Hash servers & keys onto a ring; a key is owned by the next server clockwise. Adding/removing a node only remaps keys in one segment (not all, unlike modulo hashing). Virtual nodes per server → even load + capacity-weighting. Recurs in Ch1, Ch17, Ch20, Ch24.
Fanout: write vs read (Ch11). Fanout-on-write (push to followers' caches) = fast reads, expensive for celebrities. Fanout-on-read (pull at read time) = cheap writes, slow reads. Hybrid: push for normal users, pull for high-fanout celebrities. The general "precompute vs compute-on-demand" trade-off (also Ch13, Ch14, Ch18).
Rate limiting algorithms (Ch4). Token Bucket (bursty, most common) · Leaking Bucket (smooth, FIFO) · Fixed Window (simple, edge-spike bug) · Sliding Window Log (accurate, memory-heavy) · Sliding Window Counter (smoothed hybrid). Store counters in Redis.
Money & inventory correctness (Ch21, Ch22, Ch26, Ch27). Idempotency keys prevent double-charge/double-book. Exactly-once (dedup via offset + reconciliation) for billing. Double-entry ledger for payments. Event sourcing + CQRS + Saga/TC-C for distributed wallet transactions (avoid 2PC at scale).
Queues & streaming (Ch19, Ch20, Ch21). Pull model (consumer-paced) over push. Partitions for parallelism + per-partition order; consumer groups; offsets; WAL durability; ISR for replication. Event time ≠ processing time → watermarks for late events; tumbling/sliding windows.
| # | Title | Key Frameworks |
|---|---|---|
| ch01 | Scale Zero → Millions | horizontal scaling, replication, sharding, CDN |
| ch02 | Back-of-Envelope Estimation | QPS/storage math, latency numbers, nines |
| ch03 | Interview Framework | 4-step framework |
| ch04 | Rate Limiter | token/leaking bucket, sliding window |
| ch05 | Consistent Hashing | hash ring, virtual nodes |
| ch06 | Key-Value Store | CAP, quorum, vector clock, Merkle, gossip |
| ch07 | Unique ID Generator | Snowflake bit-layout |
| ch08 | URL Shortener | Base62, hash + Bloom filter |
| ch09 | Web Crawler | BFS, URL frontier, politeness |
| ch10 | Notification System | APNS/FCM, queue decoupling, retry |
| ch11 | News Feed | fanout write/read hybrid |
| ch12 | Chat System | WebSocket, presence, service discovery |
| ch13 | Search Autocomplete | trie + cached top-k |
| ch14 | YouTube | DAG transcoding, GOP, CDN tiering |
| ch15 | Google Drive | block storage, delta sync |
| ch16 | Proximity Service | geohash, quadtree, Google S2 |
| ch17 | Nearby Friends | Redis pub/sub fanout, geohash channels |
| ch18 | Google Maps | A*, map tiling, routing tiles |
| ch19 | Message Queue | partitions, WAL, ISR, pull model |
| ch20 | Metrics & Alerting | time-series DB, pull/push, downsampling |
| ch21 | Ad Click Aggregation | lambda arch, tumbling window, exactly-once |
| ch22 | Hotel Reservation | optimistic locking, idempotency, overbooking |
| ch23 | Distributed Email | SMTP/IMAP, LSM tree, metadata DB |
| ch24 | S3 Object Storage | erasure coding, WAL, consistent hashing |
| ch25 | Gaming Leaderboard | Redis sorted set, skip list |
| ch26 | Payment System | double-entry ledger, idempotency, PSP |
| ch27 | Digital Wallet | event sourcing, CQRS, saga, TC-C |
| ch28 | Stock Exchange | matching engine, FIX, event sourcing |
When a human is studying an animatable concept — not mid-interview-design or estimation — I can build a self-contained interactive explainer via the Artifact tool (e.g. tokens dripping from a rate-limiter bucket, keys remapping on a consistent-hashing ring). I offer this for catalog concepts and generate on opt-in; an explicit "visualize this" works for any animatable concept. See visualizations.md for the trigger rules, concept catalog, and build spec.
Covers the book's content only — interview-oriented designs and the reasoning behind them. For production implementation in a real codebase, combine with project-specific tools and current vendor docs. For topics beyond these 28 chapters, ask directly.
npx claudepluginhub vukhanhtruong/system-design-skill --plugin system-designGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Reference for writing and editing skills with predictable behavior, covering invocation models, description writing, and information hierarchy.