[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7B3DBA0RWT2SA5EEXSP7CPH":3,"skill-same:01M7B3DBA0RWT2SA5EEXSP7CPH":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":14,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7B3DBA0RWT2SA5EEXSP7CPH","system-design",null,"Design scalable distributed systems using structured approaches for load balancing, caching, database scaling, and message queues. Use when the user mentions \"system design\", \"scale this\", \"high availability\", \"rate limiter\", \"design a URL shortener\", \"design Twitter\", \"design Uber\", \"design a news feed\", \"system design interview\", \"capacity planning\", or \"distributed architecture\". Also trigger when estimating infrastructure requirements, choosing between microservices and monoliths, or designing for millions of concurrent users. Covers common system designs (TinyURL, feeds, chat) and back-of-the-envelope estimation. For data fundamentals, see ddia-systems. For resilience, see release-it.","Div0011\u002FFrontend-Pipeline","Div0011","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F198384399?v=4","01M7AX16GDZ3959RM6WMDTTFV4","Div","01M7AX16HF6EPV40MA8G0G0JRC",0,"MIT","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: system-design\ndescription: 'Design scalable distributed systems using structured approaches for load balancing, caching, database scaling, and message queues. Use when the user mentions \"system design\", \"scale this\", \"high availability\", \"rate limiter\", \"design a URL shortener\", \"design Twitter\", \"design Uber\", \"design a news feed\", \"system design interview\", \"capacity planning\", or \"distributed architecture\". Also trigger when estimating infrastructure requirements, choosing between microservices and monoliths, or designing for millions of concurrent users. Covers common system designs (TinyURL, feeds, chat) and back-of-the-envelope estimation. For data fundamentals, see ddia-systems. For resilience, see release-it.'\nlicense: MIT\nmetadata:\n  author: wondelai\n  version: \"1.4.1\"\n---\n\n# System Design Framework\n\nA structured approach to designing large-scale distributed systems. Apply these principles when architecting new services, reviewing designs, estimating capacity, or preparing for system design discussions.\n\n## Core Principle\n\n**Start with requirements, not solutions.** Jumping to architecture before understanding constraints produces over- or under-engineered systems. Scalable systems are assembled from well-understood building blocks (load balancers, caches, queues, databases, CDNs) — the skill lies in choosing the right blocks, sizing them with estimates, and owning the tradeoffs each choice introduces.\n\n## Scoring\n\n**Goal: 10\u002F10.** Score a design by how many of the eight Quick Diagnostic rows it satisfies — `score = round(passed \u002F 8 × 10)`: 9-10 = all\u002Fnearly all rows pass — explicit requirements, real estimates, redundancy, a stated DB-scaling and caching strategy, async via queues, monitoring, and a deployment plan, with tradeoffs named; 5-6 = the design works but skips estimation, redundancy, or operations; \u003C=3 = architecture proposed before requirements or estimates exist. Always state the current score, name the failing diagnostic rows, and give the specific fix for each.\n\n## The System Design Framework\n\nSix areas for building reliable, scalable distributed systems:\n\n### 1. The Four-Step Process\n\n**Core concept:** Every design follows four stages: (1) understand the problem and establish scope, (2) propose a high-level design and get buy-in, (3) dive deep into critical components, (4) wrap up with tradeoffs and future improvements.\n\n**Why it works:** Without structure, designs either stay too abstract or get lost in premature detail. The four steps invest time proportionally — broad strokes first, depth where it matters.\n\n**Key insights:**\n- Step 1 (~5-10 min): clarifying questions, functional and non-functional requirements, agreed scale (DAU, QPS, storage)\n- Step 2 (~15-20 min): high-level diagram with APIs, services, data stores, data flow arrows\n- Step 3 (~15-20 min): design the 2-3 hardest or most critical components in detail\n- Step 4 (~5 min): tradeoffs, bottlenecks, future improvements\n- Never skip Step 1 — ambiguous scope wastes all downstream effort; get explicit agreement on assumptions\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **New service kickoff** | One-page design doc covering all four steps before coding | Requirements, API contract, data model, capacity estimate, then implementation |\n| **Architecture review** | Walk reviewers through the steps sequentially | Scope, diagram, deep-dive on riskiest component, open questions |\n| **Incident postmortem** | Trace the failure through the four-step lens | Which requirement was missed? Which block failed? What tradeoff bit us? |\n\nSee [references\u002Ffour-step-process.md](references\u002Ffour-step-process.md) when running a design end-to-end — per-stage time allocation, example clarifying questions, and tips for each of the four steps.\n\n### 2. Back-of-the-Envelope Estimation\n\n**Core concept:** Use powers of two, latency numbers, and simple arithmetic to estimate QPS, storage, bandwidth, and server count before committing to an architecture.\n\n**Why it works:** Estimation prevents over-provisioning (wasted money) and under-provisioning (outages under load). A 2-minute calculation can save weeks of rework.\n\n**Key insights:**\n- Powers of two: 2^10 ≈ 1 thousand, 2^20 ≈ 1 million, 2^30 ≈ 1 billion, 2^40 ≈ 1 trillion\n- Latency: memory read ~100 ns, SSD read ~100 us, disk seek ~10 ms, same-datacenter round trip ~0.5 ms, cross-continent ~150 ms\n- Availability nines: 99.9% = 8.77 hours downtime\u002Fyear; 99.99% = 52.6 minutes\u002Fyear\n- QPS: DAU x actions-per-day \u002F 86,400 seconds; peak is typically 2-5x average\n- Storage: records-per-day x record-size x retention\n- Round aggressively — the goal is order of magnitude, not precision\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Capacity planning** | Estimate QPS, multiply by growth factor | 100M DAU x 5 actions \u002F 86400 = ~5,800 QPS avg, ~30K peak |\n| **Storage budgeting** | Per-record size x volume x retention | 500M tweets\u002Fday x 300 bytes x 365 days = ~55 TB\u002Fyear |\n| **SLA definition** | Convert nines to allowed downtime | Four nines = ~52 minutes downtime per year |\n\nSee [references\u002Festimation-numbers.md](references\u002Festimation-numbers.md) when sizing a system — full latency table, availability-nines table, and worked QPS\u002Fstorage\u002Fbandwidth calculations.\n\n### 3. Building Blocks\n\n**Core concept:** Scalable systems are assembled from a standard toolkit: DNS, CDN, load balancers, reverse proxies, application servers, caches, message queues, and consistent hashing.\n\n**Why it works:** Each block trades one cost for another (a cache trades freshness for read speed; a queue trades latency for decoupling), so introduce a block only once its specific bottleneck appears — adding all of them up front just multiplies failure modes.\n\n**Key insights:**\n- Load balancers: L4 (transport layer — fast, simple) vs L7 (application layer — content-aware routing)\n- Cache layers: client, CDN, web server, application (Redis\u002FMemcached), database query cache\n- Cache strategies: cache-aside (app manages), read-through, write-through (synchronous), write-behind (asynchronous)\n- Message queues (Kafka, RabbitMQ, SQS): decouple producers from consumers, absorb spikes, enable async processing\n- Consistent hashing: distributes keys across nodes with minimal redistribution when nodes change\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Read-heavy workload** | Cache-aside Redis in front of database | Cache user profiles with TTL; invalidate on write |\n| **Traffic spikes** | Message queue between API and workers | Enqueue image-resize jobs; workers pull at their own pace |\n| **Global users** | CDN for static assets | Serve JS\u002FCSS\u002Fimages from edge; origin serves only API |\n| **Uneven load** | Consistent hashing for shard assignment | Adding a node moves only ~1\u002Fn keys |\n\nSee [references\u002Fbuilding-blocks.md](references\u002Fbuilding-blocks.md) when choosing components — how each of DNS, CDN, load balancers, caching strategies, message queues, and consistent hashing works and when to introduce it.\n\n### 4. Database Design and Scaling\n\n**Core concept:** Choose SQL vs NoSQL based on data shape and access patterns; scale vertically first, then horizontally (replication and sharding) when vertical limits are reached.\n\n**Why it works:** The database is usually the first bottleneck. Understanding replication, sharding, and denormalization tradeoffs delays expensive re-architectures and makes growth deliberate.\n\n**Key insights:**\n- Vertical scaling is simpler but has a ceiling; horizontal is harder but nearly unlimited\n- Replication: leader-follower (one writer, many readers) for read-heavy; multi-leader for multi-region writes\n- Sharding: hash-based (even distribution, hard range queries), range-based (easy ranges, hotspot risk), directory-based (flexible, extra lookup)\n- SQL for ACID transactions, joins, defined schema; NoSQL for flexible schema, horizontal scale, very high write throughput\n- Denormalization trades storage and write complexity for read speed — use when reads dominate and data changes rarely\n- Celebrity\u002Fhotspot problem: one hot shard needs secondary partitioning or a cache layer\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Read-heavy API** | Leader-follower with read replicas | Reads to replicas, writes to leader; accept slight lag |\n| **User data at scale** | Hash-based sharding on user_id | hash(user_id) % num_shards; even, independent shards |\n| **Analytics dashboard** | Denormalized materialized views | Pre-join and aggregate nightly; serve from materialized table |\n\nSee [references\u002Fdatabase-scaling.md](references\u002Fdatabase-scaling.md) when the database is the bottleneck — replication topologies, the three sharding strategies compared, denormalization tradeoffs, and a SQL-vs-NoSQL selection guide.\n\n### 5. Common System Designs\n\n**Core concept:** Most systems are variations of a small set of well-known designs: URL shortener, rate limiter, notification system, news feed, chat, search autocomplete, web crawler, unique ID generator.\n\n**Why it works:** A mental library of known designs lets you recognize which pattern a new problem resembles and adapt it, rather than inventing from scratch.\n\n**Key insights:**\n- URL shortener: base62 encoding, key-value store, 301 vs 302 redirect tradeoff (caching vs analytics)\n- Rate limiter: token bucket or sliding window at the gateway; return 429 with Retry-After\n- News feed: fanout-on-write (push at post time) vs fanout-on-read (pull at read time); hybrid for celebrities\n- Chat: WebSocket for real-time bidirectional messages, queue for delivery guarantees, heartbeat presence service\n- Autocomplete: trie of top-k frequent queries; precompute and cache popular prefixes\n- Web crawler: BFS with URL frontier, politeness (robots.txt, per-domain rate limit), dedup via content hash\n- Unique IDs: UUID (simple, no coordination) vs Snowflake (64-bit, time-sortable, datacenter-aware)\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Short link service** | Base62-encode auto-increment ID or hash | `https:\u002F\u002Fshort.ly\u002Fa1B2c3` maps to a key-value row |\n| **API protection** | Token bucket at gateway | 100 tokens\u002Fmin per key; steady refill; reject with 429 |\n| **Social feed** | Hybrid fanout | Precompute feeds for \u003C10K-follower accounts; merge celebrity posts at read time |\n\nSee [references\u002Fcommon-designs.md](references\u002Fcommon-designs.md) when a problem resembles a known design — full walkthroughs of URL shortener, rate limiter, news feed, chat, autocomplete, web crawler, and unique ID generator.\n\n### 6. Reliability and Operations\n\n**Core concept:** A system is only as good as its ability to stay up, recover, and be observed. Health checks, monitoring, logging, and deployment strategies are first-class design concerns, not afterthoughts.\n\n**Why it works:** Production systems fail in ways diagrams never predict. Operational readiness — metrics, alerts, rollback plans, redundancy — determines whether a failure is a blip or an outage.\n\n**Key insights:**\n- Health checks: liveness (is the process alive?) and readiness (can it serve traffic?) — Kubernetes uses both\n- Three pillars of observability: metrics (Prometheus, Datadog), logging (ELK, CloudWatch), tracing (Jaeger, Zipkin)\n- Deployments: rolling (gradual), blue-green (instant switch between identical environments), canary (small percentage first)\n- Disaster recovery: RPO (acceptable data loss) and RTO (acceptable recovery time) drive backup and failover strategy\n- Multi-datacenter: active-passive (failover) or active-active (requires data sync and conflict resolution)\n- Autoscaling: scale on CPU, memory, queue depth, or custom metrics; always set min and max counts\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Zero-downtime deploy** | Blue-green with health check gates | Switch to green after checks pass; keep blue as instant rollback |\n| **Gradual rollout** | Canary with metric comparison | 5% traffic to new version; compare errors and latency; promote or rollback |\n| **Data safety** | Define RPO\u002FRTO, implement accordingly | RPO 1 hour = hourly backups; RTO 5 min = automated failover |\n\nSee [references\u002Freliability-operations.md](references\u002Freliability-operations.md) when hardening for production — health-check patterns, the observability pillars, deployment strategies, disaster-recovery (RPO\u002FRTO), and autoscaling.\n\n## Common Mistakes\n\n| Mistake | Why It Fails | Fix |\n|---------|-------------|------|\n| **Architecture before requirements** | Solves the wrong problem, misses constraints | Spend the first 5-10 minutes on scope: features, scale, SLA |\n| **No estimation** | Provisioning off by orders of magnitude | Estimate QPS, storage, bandwidth before choosing components |\n| **Single point of failure** | One component takes down the system | Redundancy at every layer: multi-server, multi-AZ, multi-region |\n| **Premature sharding** | Huge operational complexity before it's needed | Vertical first, read replicas, cache aggressively, shard last |\n| **Caching without invalidation** | Stale data causes bugs and confusion | Define TTL; cache-aside with explicit invalidation on writes |\n| **Synchronous calls everywhere** | One slow service cascades latency to all callers | Queues for non-latency-critical paths; timeouts on sync calls |\n| **Ignoring hotspots** | One shard or key hammered, others idle | Detect hot keys; add secondary partitioning or local caches |\n| **No monitoring or alerting** | Users find failures before you do | Instrument metrics, logs, and traces from day one |\n\n## Quick Diagnostic\n\n| Question | If No | Action |\n|----------|-------|--------|\n| Are functional and non-functional requirements listed? | Design rests on assumptions | Write down features, DAU, QPS, storage, latency and availability SLAs |\n| Is there a QPS and storage estimate? | Capacity is a guess | DAU x actions \u002F 86400 for QPS; records x size x retention for storage |\n| Is every component redundant? | Single points of failure | Add replicas, failover, or multi-AZ per component |\n| Is the database scaling strategy defined? | You hit a wall under growth | Vertical first, then read replicas, then sharding with a clear shard key |\n| Is there a cache for read-heavy paths? | Database takes unnecessary load | Redis\u002FMemcached cache-aside with defined TTL |\n| Are async paths using queues? | Tight coupling, cascading failures | Decouple with Kafka\u002FSQS for jobs, notifications, analytics |\n| Is there a monitoring and alerting plan? | Blind to production failures | Define metrics, log aggregation, tracing, alert thresholds |\n| Is the deployment strategy defined? | Risky all-at-once releases | Rolling, blue-green, or canary with automated rollback |\n\n## Further Reading\n\nFor the complete guides with detailed diagrams and walkthroughs:\n\n- [*\"System Design Interview -- An Insider's Guide\"*](https:\u002F\u002Fwww.amazon.com\u002FSystem-Design-Interview-insiders-Second\u002Fdp\u002FB08CMF2CQF?tag=wondelai00-20) by Alex Xu (Volume 1)\n- [*\"System Design Interview -- An Insider's Guide: Volume 2\"*](https:\u002F\u002Fwww.amazon.com\u002FSystem-Design-Interview-Insiders-Guide\u002Fdp\u002F1736049119?tag=wondelai00-20) by Alex Xu (Volume 2)\n- [*\"Designing Data-Intensive Applications\"*](https:\u002F\u002Fwww.amazon.com\u002FDesigning-Data-Intensive-Applications-Reliable-Maintainable\u002Fdp\u002F1449373321?tag=wondelai00-20) by Martin Kleppmann (data systems fundamentals)\n- [ByteByteGo](https:\u002F\u002Fbytebytego.com\u002F) -- Alex Xu's platform with visual system design explanations\n\n## About the Author\n\n**Alex Xu** is a software engineer who previously worked at Twitter, Apple, and Oracle, and the creator of ByteByteGo. His two-volume *System Design Interview* series, with over 500,000 copies sold, turned system design into a learnable, repeatable skill through structured thinking, estimation, and clear communication.\n","# System Design Framework\n\nA structured approach to designing large-scale distributed systems. Apply these principles when architecting new services, reviewing designs, estimating capacity, or preparing for system design discussions.\n\n## Core Principle\n\n**Start with requirements, not solutions.** Jumping to architecture before understanding constraints produces over- or under-engineered systems. Scalable systems are assembled from well-understood building blocks (load balancers, caches, queues, databases, CDNs) — the skill lies in choosing the right blocks, sizing them with estimates, and owning the tradeoffs each choice introduces.\n\n## Scoring\n\n**Goal: 10\u002F10.** Score a design by how many of the eight Quick Diagnostic rows it satisfies — `score = round(passed \u002F 8 × 10)`: 9-10 = all\u002Fnearly all rows pass — explicit requirements, real estimates, redundancy, a stated DB-scaling and caching strategy, async via queues, monitoring, and a deployment plan, with tradeoffs named; 5-6 = the design works but skips estimation, redundancy, or operations; \u003C=3 = architecture proposed before requirements or estimates exist. Always state the current score, name the failing diagnostic rows, and give the specific fix for each.\n\n## The System Design Framework\n\nSix areas for building reliable, scalable distributed systems:\n\n### 1. The Four-Step Process\n\n**Core concept:** Every design follows four stages: (1) understand the problem and establish scope, (2) propose a high-level design and get buy-in, (3) dive deep into critical components, (4) wrap up with tradeoffs and future improvements.\n\n**Why it works:** Without structure, designs either stay too abstract or get lost in premature detail. The four steps invest time proportionally — broad strokes first, depth where it matters.\n\n**Key insights:**\n- Step 1 (~5-10 min): clarifying questions, functional and non-functional requirements, agreed scale (DAU, QPS, storage)\n- Step 2 (~15-20 min): high-level diagram with APIs, services, data stores, data flow arrows\n- Step 3 (~15-20 min): design the 2-3 hardest or most critical components in detail\n- Step 4 (~5 min): tradeoffs, bottlenecks, future improvements\n- Never skip Step 1 — ambiguous scope wastes all downstream effort; get explicit agreement on assumptions\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **New service kickoff** | One-page design doc covering all four steps before coding | Requirements, API contract, data model, capacity estimate, then implementation |\n| **Architecture review** | Walk reviewers through the steps sequentially | Scope, diagram, deep-dive on riskiest component, open questions |\n| **Incident postmortem** | Trace the failure through the four-step lens | Which requirement was missed? Which block failed? What tradeoff bit us? |\n\nSee [references\u002Ffour-step-process.md](references\u002Ffour-step-process.md) when running a design end-to-end — per-stage time allocation, example clarifying questions, and tips for each of the four steps.\n\n### 2. Back-of-the-Envelope Estimation\n\n**Core concept:** Use powers of two, latency numbers, and simple arithmetic to estimate QPS, storage, bandwidth, and server count before committing to an architecture.\n\n**Why it works:** Estimation prevents over-provisioning (wasted money) and under-provisioning (outages under load). A 2-minute calculation can save weeks of rework.\n\n**Key insights:**\n- Powers of two: 2^10 ≈ 1 thousand, 2^20 ≈ 1 million, 2^30 ≈ 1 billion, 2^40 ≈ 1 trillion\n- Latency: memory read ~100 ns, SSD read ~100 us, disk seek ~10 ms, same-datacenter round trip ~0.5 ms, cross-continent ~150 ms\n- Availability nines: 99.9% = 8.77 hours downtime\u002Fyear; 99.99% = 52.6 minutes\u002Fyear\n- QPS: DAU x actions-per-day \u002F 86,400 seconds; peak is typically 2-5x average\n- Storage: records-per-day x record-size x retention\n- Round aggressively — the goal is order of magnitude, not precision\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Capacity planning** | Estimate QPS, multiply by growth factor | 100M DAU x 5 actions \u002F 86400 = ~5,800 QPS avg, ~30K peak |\n| **Storage budgeting** | Per-record size x volume x retention | 500M tweets\u002Fday x 300 bytes x 365 days = ~55 TB\u002Fyear |\n| **SLA definition** | Convert nines to allowed downtime | Four nines = ~52 minutes downtime per year |\n\nSee [references\u002Festimation-numbers.md](references\u002Festimation-numbers.md) when sizing a system — full latency table, availability-nines table, and worked QPS\u002Fstorage\u002Fbandwidth calculations.\n\n### 3. Building Blocks\n\n**Core concept:** Scalable systems are assembled from a standard toolkit: DNS, CDN, load balancers, reverse proxies, application servers, caches, message queues, and consistent hashing.\n\n**Why it works:** Each block trades one cost for another (a cache trades freshness for read speed; a queue trades latency for decoupling), so introduce a block only once its specific bottleneck appears — adding all of them up front just multiplies failure modes.\n\n**Key insights:**\n- Load balancers: L4 (transport layer — fast, simple) vs L7 (application layer — content-aware routing)\n- Cache layers: client, CDN, web server, application (Redis\u002FMemcached), database query cache\n- Cache strategies: cache-aside (app manages), read-through, write-through (synchronous), write-behind (asynchronous)\n- Message queues (Kafka, RabbitMQ, SQS): decouple producers from consumers, absorb spikes, enable async processing\n- Consistent hashing: distributes keys across nodes with minimal redistribution when nodes change\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Read-heavy workload** | Cache-aside Redis in front of database | Cache user profiles with TTL; invalidate on write |\n| **Traffic spikes** | Message queue between API and workers | Enqueue image-resize jobs; workers pull at their own pace |\n| **Global users** | CDN for static assets | Serve JS\u002FCSS\u002Fimages from edge; origin serves only API |\n| **Uneven load** | Consistent hashing for shard assignment | Adding a node moves only ~1\u002Fn keys |\n\nSee [references\u002Fbuilding-blocks.md](references\u002Fbuilding-blocks.md) when choosing components — how each of DNS, CDN, load balancers, caching strategies, message queues, and consistent hashing works and when to introduce it.\n\n### 4. Database Design and Scaling\n\n**Core concept:** Choose SQL vs NoSQL based on data shape and access patterns; scale vertically first, then horizontally (replication and sharding) when vertical limits are reached.\n\n**Why it works:** The database is usually the first bottleneck. Understanding replication, sharding, and denormalization tradeoffs delays expensive re-architectures and makes growth deliberate.\n\n**Key insights:**\n- Vertical scaling is simpler but has a ceiling; horizontal is harder but nearly unlimited\n- Replication: leader-follower (one writer, many readers) for read-heavy; multi-leader for multi-region writes\n- Sharding: hash-based (even distribution, hard range queries), range-based (easy ranges, hotspot risk), directory-based (flexible, extra lookup)\n- SQL for ACID transactions, joins, defined schema; NoSQL for flexible schema, horizontal scale, very high write throughput\n- Denormalization trades storage and write complexity for read speed — use when reads dominate and data changes rarely\n- Celebrity\u002Fhotspot problem: one hot shard needs secondary partitioning or a cache layer\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Read-heavy API** | Leader-follower with read replicas | Reads to replicas, writes to leader; accept slight lag |\n| **User data at scale** | Hash-based sharding on user_id | hash(user_id) % num_shards; even, independent shards |\n| **Analytics dashboard** | Denormalized materialized views | Pre-join and aggregate nightly; serve from materialized table |\n\nSee [references\u002Fdatabase-scaling.md](references\u002Fdatabase-scaling.md) when the database is the bottleneck — replication topologies, the three sharding strategies compared, denormalization tradeoffs, and a SQL-vs-NoSQL selection guide.\n\n### 5. Common System Designs\n\n**Core concept:** Most systems are variations of a small set of well-known designs: URL shortener, rate limiter, notification system, news feed, chat, search autocomplete, web crawler, unique ID generator.\n\n**Why it works:** A mental library of known designs lets you recognize which pattern a new problem resembles and adapt it, rather than inventing from scratch.\n\n**Key insights:**\n- URL shortener: base62 encoding, key-value store, 301 vs 302 redirect tradeoff (caching vs analytics)\n- Rate limiter: token bucket or sliding window at the gateway; return 429 with Retry-After\n- News feed: fanout-on-write (push at post time) vs fanout-on-read (pull at read time); hybrid for celebrities\n- Chat: WebSocket for real-time bidirectional messages, queue for delivery guarantees, heartbeat presence service\n- Autocomplete: trie of top-k frequent queries; precompute and cache popular prefixes\n- Web crawler: BFS with URL frontier, politeness (robots.txt, per-domain rate limit), dedup via content hash\n- Unique IDs: UUID (simple, no coordination) vs Snowflake (64-bit, time-sortable, datacenter-aware)\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Short link service** | Base62-encode auto-increment ID or hash | `https:\u002F\u002Fshort.ly\u002Fa1B2c3` maps to a key-value row |\n| **API protection** | Token bucket at gateway | 100 tokens\u002Fmin per key; steady refill; reject with 429 |\n| **Social feed** | Hybrid fanout | Precompute feeds for \u003C10K-follower accounts; merge celebrity posts at read time |\n\nSee [references\u002Fcommon-designs.md](references\u002Fcommon-designs.md) when a problem resembles a known design — full walkthroughs of URL shortener, rate limiter, news feed, chat, autocomplete, web crawler, and unique ID generator.\n\n### 6. Reliability and Operations\n\n**Core concept:** A system is only as good as its ability to stay up, recover, and be observed. Health checks, monitoring, logging, and deployment strategies are first-class design concerns, not afterthoughts.\n\n**Why it works:** Production systems fail in ways diagrams never predict. Operational readiness — metrics, alerts, rollback plans, redundancy — determines whether a failure is a blip or an outage.\n\n**Key insights:**\n- Health checks: liveness (is the process alive?) and readiness (can it serve traffic?) — Kubernetes uses both\n- Three pillars of observability: metrics (Prometheus, Datadog), logging (ELK, CloudWatch), tracing (Jaeger, Zipkin)\n- Deployments: rolling (gradual), blue-green (instant switch between identical environments), canary (small percentage first)\n- Disaster recovery: RPO (acceptable data loss) and RTO (acceptable recovery time) drive backup and failover strategy\n- Multi-datacenter: active-passive (failover) or active-active (requires data sync and conflict resolution)\n- Autoscaling: scale on CPU, memory, queue depth, or custom metrics; always set min and max counts\n\n**Code applications:**\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Zero-downtime deploy** | Blue-green with health check gates | Switch to green after checks pass; keep blue as instant rollback |\n| **Gradual rollout** | Canary with metric comparison | 5% traffic to new version; compare errors and latency; promote or rollback |\n| **Data safety** | Define RPO\u002FRTO, implement accordingly | RPO 1 hour = hourly backups; RTO 5 min = automated failover |\n\nSee [references\u002Freliability-operations.md](references\u002Freliability-operations.md) when hardening for production — health-check patterns, the observability pillars, deployment strategies, disaster-recovery (RPO\u002FRTO), and autoscaling.\n\n## Common Mistakes\n\n| Mistake | Why It Fails | Fix |\n|---------|-------------|------|\n| **Architecture before requirements** | Solves the wrong problem, misses constraints | Spend the first 5-10 minutes on scope: features, scale, SLA |\n| **No estimation** | Provisioning off by orders of magnitude | Estimate QPS, storage, bandwidth before choosing components |\n| **Single point of failure** | One component takes down the system | Redundancy at every layer: multi-server, multi-AZ, multi-region |\n| **Premature sharding** | Huge operational complexity before it's needed | Vertical first, read replicas, cache aggressively, shard last |\n| **Caching without invalidation** | Stale data causes bugs and confusion | Define TTL; cache-aside with explicit invalidation on writes |\n| **Synchronous calls everywhere** | One slow service cascades latency to all callers | Queues for non-latency-critical paths; timeouts on sync calls |\n| **Ignoring hotspots** | One shard or key hammered, others idle | Detect hot keys; add secondary partitioning or local caches |\n| **No monitoring or alerting** | Users find failures before you do | Instrument metrics, logs, and traces from day one |\n\n## Quick Diagnostic\n\n| Question | If No | Action |\n|----------|-------|--------|\n| Are functional and non-functional requirements listed? | Design rests on assumptions | Write down features, DAU, QPS, storage, latency and availability SLAs |\n| Is there a QPS and storage estimate? | Capacity is a guess | DAU x actions \u002F 86400 for QPS; records x size x retention for storage |\n| Is every component redundant? | Single points of failure | Add replicas, failover, or multi-AZ per component |\n| Is the database scaling strategy defined? | You hit a wall under growth | Vertical first, then read replicas, then sharding with a clear shard key |\n| Is there a cache for read-heavy paths? | Database takes unnecessary load | Redis\u002FMemcached cache-aside with defined TTL |\n| Are async paths using queues? | Tight coupling, cascading failures | Decouple with Kafka\u002FSQS for jobs, notifications, analytics |\n| Is there a monitoring and alerting plan? | Blind to production failures | Define metrics, log aggregation, tracing, alert thresholds |\n| Is the deployment strategy defined? | Risky all-at-once releases | Rolling, blue-green, or canary with automated rollback |\n\n## Further Reading\n\nFor the complete guides with detailed diagrams and walkthroughs:\n\n- [*\"System Design Interview -- An Insider's Guide\"*](https:\u002F\u002Fwww.amazon.com\u002FSystem-Design-Interview-insiders-Second\u002Fdp\u002FB08CMF2CQF?tag=wondelai00-20) by Alex Xu (Volume 1)\n- [*\"System Design Interview -- An Insider's Guide: Volume 2\"*](https:\u002F\u002Fwww.amazon.com\u002FSystem-Design-Interview-Insiders-Guide\u002Fdp\u002F1736049119?tag=wondelai00-20) by Alex Xu (Volume 2)\n- [*\"Designing Data-Intensive Applications\"*](https:\u002F\u002Fwww.amazon.com\u002FDesigning-Data-Intensive-Applications-Reliable-Maintainable\u002Fdp\u002F1449373321?tag=wondelai00-20) by Martin Kleppmann (data systems fundamentals)\n- [ByteByteGo](https:\u002F\u002Fbytebytego.com\u002F) -- Alex Xu's platform with visual system design explanations\n\n## About the Author\n\n**Alex Xu** is a software engineer who previously worked at Twitter, Apple, and Oracle, and the creator of ByteByteGo. His two-volume *System Design Interview* series, with over 500,000 copies sold, turned system design into a learnable, repeatable skill through structured thinking, estimation, and clear communication.\n",{"name":5,"license":15,"metadata":24,"description":7},{"author":25,"version":26},"wondelai","1.4.1","main","ba06aff3a0c008524409a6bdcf301dfe4e8f165b",".agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline","https:\u002F\u002Fgithub.com\u002FDiv0011","B.Tech Computer Engineering undergrad & Full-Stack Developer. Specialized in Generative AI, Next.js, and Python architecture. Building autonomous systems.","2026-09-07 19:51:50",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add Div0011\u002FFrontend-Pipeline --skill system-design",{"tool":40,"command":41},"bunx","bunx skills add Div0011\u002FFrontend-Pipeline --skill system-design",{"tool":43,"command":44},"pnpm","pnpm dlx skills add Div0011\u002FFrontend-Pipeline --skill system-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002FSKILL.md",true,[48,54,58,62,66,70],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002Fbuilding-blocks.md","REFERENCE","参考文档",11730,"https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002Freferences\u002Fbuilding-blocks.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002Fcommon-designs.md",12139,"https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002Freferences\u002Fcommon-designs.md",{"path":59,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":60,"sourceHtmlUrl":61},"references\u002Fdatabase-scaling.md",11386,"https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002Freferences\u002Fdatabase-scaling.md",{"path":63,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Festimation-numbers.md",8617,"https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002Freferences\u002Festimation-numbers.md",{"path":67,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Ffour-step-process.md",10151,"https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002Freferences\u002Ffour-step-process.md",{"path":71,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Freliability-operations.md",13914,"https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwondelai-skills\u002F.cursor\u002Fskills\u002Fsystem-design\u002Freferences\u002Freliability-operations.md",[75,84,91,98,105,112],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":79,"licenseFileUrl":80,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M7B9FY1YN4AX6XSKFY1GEB6F","scrapling-official","Scrape web pages using Scrapling with anti-bot bypass (like Cloudflare Turnstile), stealth headless browsing, spiders framework, adaptive scraping, and JavaScript rendering. Use when asked to scrape, crawl, or extract data from websites; web_fetch fails; the site has anti-bot protections; write Python code to scrape\u002Fcrawl; or write spiders.","BSD-3-Clause","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002Fartifacts\u002Fvendor_references\u002FScrapling\u002Fagent-skill\u002FScrapling-Skill\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002Fartifacts\u002Fvendor_references\u002FScrapling\u002Fagent-skill\u002FScrapling-Skill\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7B9FNH5E90KCTDK1MABVBAX","working-with-legacy-code","Safely change and test untested codebases using Feathers' \"Working Effectively with Legacy Code\". Use when the user mentions \"legacy code\", \"no tests\", \"untested codebase\", \"how do I test this\", \"seams\", \"characterization tests\", \"golden master\", \"sprout method\", \"afraid to change this code\", \"monster method\", \"dependency breaking\", or \"inherited a messy codebase\". Also trigger when changing code without tests safely, getting a class under test when constructors, statics, or singletons block it, adding features to tangled modules, or planning incremental test coverage for an old codebase. Covers the legacy-code change algorithm, seams, characterization tests, sprout\u002Fwrap, and dependency-breaking techniques. For refactoring code that already has tests, see refactoring-patterns. For day-to-day code quality, see clean-code.","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002Fartifacts\u002Fskills\u002Fwondelai-skills\u002Fworking-with-legacy-code\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":19},"01M7B9FDRG6DG9PKTEMKZXHCXY","web-typography","Select, pair, and implement typefaces for web projects. Use when the user mentions \"font pairing\", \"which typeface\", \"line height\", \"responsive typography\", \"web font loading\", \"type hierarchy\", \"variable fonts\", \"FOUT\u002FFOIT\", \"typographic scale\", or \"the text is hard to read\". Also trigger when choosing between system fonts and web fonts, optimizing font-loading performance, or designing readable long-form content. Covers readability evaluation, CSS implementation, and performance optimization. For overall UI design systems, see refactoring-ui. For dramatic typographic experiences, see top-design.","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002Fartifacts\u002Fskills\u002Fwondelai-skills\u002Fweb-typography\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":19},"01M7B9F6P2Y8R413YJ3WX339HH","ux-heuristics","Evaluate and improve interface usability using heuristic analysis. Use when the user mentions \"usability audit\", \"users are confused\", \"form usability\", \"navigation problems\", \"Nielsen heuristics\", \"cognitive walkthrough\", or \"is this easy to use\". Also trigger when reviewing a design for usability issues, improving form-completion rates, or evaluating information architecture and navigation. Covers Krug's laws, Nielsen's 10 heuristics, severity ratings, dark-pattern recognition, and accessibility. For visual design fixes, see refactoring-ui. For conversion-focused audits, see cro-methodology.","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002Fartifacts\u002Fskills\u002Fwondelai-skills\u002Fux-heuristics\u002FSKILL.md",[],[],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":19},"01M7B9EZVNSBCXJFQRFVX29NR5","traction-eos","Implement the Entrepreneurial Operating System (EOS) to align vision and execution across a company. Use when the user mentions \"EOS\", \"Entrepreneurial Operating System\", \"V\u002FTO\", \"quarterly rocks\", \"Level 10 meetings\", \"accountability chart\", \"IDS process\", \"my company feels chaotic\", \"we keep having the same problems\", or \"get the whole team aligned\". Also trigger when a growing company needs meeting structure, goal-setting frameworks, or a systematic way to solve recurring organizational issues. Covers the six EOS components: Vision, People, Data, Issues, Process, Traction. For team motivation design, see drive-motivation. For lean experimentation, see lean-startup.","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002Fartifacts\u002Fskills\u002Fwondelai-skills\u002Ftraction-eos\u002FSKILL.md",[],[],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":19},"01M7B9ESTNAY9WY8NFW590DWGA","top-design","Create award-winning, immersive web experiences at the level of Awwwards-featured agencies. Use when the user mentions \"Awwwards quality\", \"make my site stunning\", \"scroll animations\", \"parallax storytelling\", \"cinematic web design\", \"portfolio site\", or \"brand experience\". Also trigger when elevating a standard landing page into a memorable digital experience. Covers dramatic typography, purposeful motion, scroll-based composition, and performance-optimized animation. For foundational UI, see refactoring-ui. For type selection, see web-typography.","https:\u002F\u002Fgithub.com\u002FDiv0011\u002FFrontend-Pipeline\u002Fblob\u002Fmain\u002Fartifacts\u002Fskills\u002Fwondelai-skills\u002Ftop-design\u002FSKILL.md",[],[]]