Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-sd-case-studies
25 real-world system design case studies condensed from Alex Xu's System Design Interview Vol 1 and 2 - requirements, architecture, deep dive insights, key takeaways
Passed 19 of 22 test cases with the skill, and 18 of 22 without it.
2 fixed17 passed either way2 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are designing a hotel room booking platform subject to extreme flash sales where thousands of customers attempt to book the last remaining room simultaneously. Designers suggest acquiring pessimistic distributed locks across all room records during checkout. Deliver an architectural recommendation for concurrency control and database updates.
| Checked | Without skill | With skill |
|---|---|---|
| use optimistic locking | Missed | Passed |
| apply conditional database updates checking room availability | Passed | Passed |
The instructions your model reads when the skill loads.
Reference catalog of 25 real-world designs. Use when designing a similar system or needing precedent for architectural decisions.
Scale: API gateway middleware | Core: Token Bucket (industry standard) or Sliding Window Counter | Storage: Redis counters with TTL | Distributed: Lua scripts for atomic increment | Key insight: cross-cutting concern, belongs in middleware/gateway | Headers: 429 + Retry-After + X-RateLimit-Remaining
Core: hash ring 0 to 2^32-1, servers at positions, keys walk clockwise | Virtual nodes: 100-200 per server, reduces load deviation from ~40% to ~5% | Used in: DynamoDB, Cassandra, Akamai, Discord | Key insight: never deploy without virtual nodes
Core: consistent hashing for partitioning, N replicas on clockwise nodes, quorum W+R>N | Conflict: vector clocks, LWW, app-level merge | Failures: sloppy quorum + hinted handoff (temp), Merkle trees + anti-entropy (permanent), gossip for detection | Write path: WAL -> memtable -> SSTable (LSM-tree) | Read path: memtable -> Bloom filter -> SSTable(s)
Winner: Snowflake -- 64-bit, sortable, minimal coordination | [1 unused | 41 timestamp | 5 DC | 5 machine | 12 sequence] ~4M IDs/sec/DC | Weakness: clock sync (NTP) | Alt: UUID (128-bit, not sortable), ticket server (SPOF)
Scale: 100M/day ~ 1,160 QPS write, 11,600 read | Short URL: base62 with 7 chars = 3.5T combinations | Approaches: hash + collision resolution | base62 from auto-increment ID | pre-generated key service | Redirect: 301 (cached, no analytics) vs 302 (every click tracked) -- most use 302 | Key: caching critical (heavy-tailed distribution)
Scale: 1B pages/month ~ 400 pages/sec, 500TB storage/month | Core: URL Frontier with priority queues (importance) + politeness queues (per-domain rate limit) | Dedup: SHA-256 exact, simhash/MinHash near-duplicate | Traps: URL length limit, max depth, blacklist | Key insight: URL frontier is the most important component
Scale: 10M push, 1M SMS, 5M email/day | Architecture: Services -> Message Queue -> Workers -> Third-party (APNs, FCM, Twilio, SES) | Reliability: persist before sending, retry with exponential backoff, dedup via event_id | Key: decouple creation from delivery; user preferences are critical
Core: hybrid fan-out -- push for normal users (<10K followers), pull for celebrities | Feed cache: pre-computed for most users, celebrity posts merged at read time | Ranking: chronological simplest; ML-based for engagement optimization | Pagination: cursor-based (not offset) | Media: object storage + CDN
Scale: 50M DAU | Protocol: WebSocket (bidirectional, persistent) | Storage: KV store (HBase-like), partition by channel_id | 1-on-1: message via WebSocket -> store -> push to recipient (or notification if offline) | Group (<100): fan-out on write to member inboxes | Presence: heartbeat every 5s, offline after 30s missed, lazy propagation for large friend lists | Multi-device: per-device cursor of last-read message
Scale: 24K QPS avg, 48K peak | Core: trie with cached top-K at each node, O(prefix_length) query | Update: offline aggregation (weekly rebuild), NOT real-time; separate trending pipeline | Scaling: shard by first character(s), replicate each shard | Client: debounce 100-200ms, cache recent results, pre-fetch
Scale: 5M DAU, 150TB storage/day | Upload: upload -> transcoding queue -> workers (DAG pipeline: split->encode->merge) -> object storage -> CDN | Streaming: adaptive bitrate (DASH/HLS), manifest + segment-based | Transcoding: multiple resolutions (360p-4K) + formats (H.264, VP9, AV1) | Cost: popular videos on CDN, long-tail from origin; encode popular formats eagerly
test cases passed, vs 18 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.