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.
Guides 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.
npx claudepluginhub vukhanhtruong/system-design-skill --plugin system-design