[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WYAN83XG2RG9FVFRNJRGQP":3,"skill-same:01M6WYAN83XG2RG9FVFRNJRGQP":88},{"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":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":14,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M6WYAN83XG2RG9FVFRNJRGQP","system-design",null,"System design methodology — requirements, capacity estimation, component design, trade-offs. Use when designing a new distributed system, evaluating an existing architecture for scalability or cost, performing back-of-envelope capacity estimation, or preparing for a system design review.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.13.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fsystem-design\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,5,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"design","system","system design","when","trade-offs","Existing","for","v1","estimation","scalability","back","use","work","distributed system","distributed","architecture","component","design review","review","2026-11-10 10:12:30",false,"---\nname: system-design\ndescription: |\n  System design methodology — requirements, capacity estimation, component design, trade-offs. Use when designing a new distributed system, evaluating an existing architecture for scalability or cost, performing back-of-envelope capacity estimation, or preparing for a system design review.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-system-design\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# System Design\n\n## Intro\n\nSystem design starts with requirements, not boxes. Estimate capacity\non the back of an envelope, draw a small high-level architecture,\nthen deep-dive only the components that are unique or risky. Make\ntrade-offs explicit — every design decision has a cost.\n\n## Overview\n\n### Gather requirements\n\nAlways start with requirements. Split them into functional and\nnon-functional.\n\n**Functional:** what does the system do? Core use cases (2-4 most\nimportant), user-facing vs internal features, data formats, and key\nend-to-end workflows.\n\n**Non-functional:** how well must it do it?\n\n- **Scale** — DAU, peak QPS, data volume\n- **Latency** — p50 and p99 targets\n- **Availability** — 99.9%, 99.99%, or higher (and the downtime\n  budget that implies)\n- **Consistency** — strong or eventual, and which parts need which\n- **Durability** — RPO\u002FRTO targets, can we lose data\n- **Security** — auth, encryption, compliance constraints\n- **Cost** — budget, managed vs self-hosted preference\n\nDo not over-specify. Focus on what differentiates this system from a\ngeneric CRUD app.\n\n### Capacity estimation\n\nNumbers and formulas live in `references\u002Festimation-cheatsheet.md`.\n\nBack-of-envelope framework:\n\n1. **Users** — DAU -> peak concurrent -> requests per second\n2. **Storage** — data per record * records per day * retention\n3. **Bandwidth** — request size * QPS in + response size * QPS out\n4. **Compute** — QPS \u002F requests-per-instance = instance count\n\nState assumptions explicitly: read:write ratio (most systems are\n10:1 to 100:1), peak-to-average ratio (typically 3x-10x), data\ngrowth rate (linear or exponential), and cache hit rate (often\n80-95% for read-heavy workloads).\n\n### High-level design\n\nDraw 5-10 major components. Start with the client and work inward.\nFor each core use case, trace the data flow with numbered arrows.\nPlace standard infrastructure where it belongs: load balancer, API\ngateway, CDN, cache, database, queue. For each kind of data, choose\na store (relational, document, blob, cache, search index). Keep it\nsimple first; add complexity only when requirements demand it.\n\n### Component deep dives\n\nFor each critical component, detail:\n\n- **API design** — endpoints, request\u002Fresponse formats, pagination\n- **Data model** — schema, indexing, partitioning\u002Fsharding key\n- **Scaling strategy** — horizontal vs vertical, stateless vs\n  stateful\n- **Failure handling** — what happens when this component dies\n- **Caching** — what is cached, where (client, CDN, app, DB), TTL,\n  invalidation\n\nFocus deep dives on components that are unique to this system or\nmost likely to be bottlenecks. Don't deep-dive a stock load\nbalancer.\n\n### Trade-off analysis\n\nEvery decision has trade-offs. State the side you chose and why,\ngiven the requirements:\n\n- **Consistency vs availability** — CAP theorem; in a partition you\n  pick C or A\n- **Latency vs throughput** — batching raises throughput at the cost\n  of latency\n- **Simplicity vs scalability** — simpler designs are easier to\n  operate but may not scale\n- **Cost vs performance** — caching reduces latency but raises\n  infrastructure cost\n- **Flexibility vs optimization** — denormalization speeds reads but\n  complicates writes\n\n### Scalability patterns\n\n- **Horizontal scaling** — stateless services behind a load balancer\n- **Database sharding** — partition by user ID, tenant ID, or region\n- **Read replicas** — offload reads, accept replication lag\n- **Caching layers** — local cache -> distributed cache (Redis) ->\n  CDN\n- **Async processing** — push non-critical work onto background\n  queues\n- **Event-driven decoupling** — pub\u002Fsub between producers and\n  consumers\n- **Rate limiting** — token bucket, sliding window\n- **Circuit breakers** — prevent cascade failures when downstream is\n  unhealthy\n\n### Example workflows\n\n- **URL shortener:** create \u002F redirect \u002F analytics. 100M URLs\u002Fmonth,\n  \u003C100ms redirect, 99.99% availability. ~40 writes\u002Fs, ~4000 reads\u002Fs,\n  ~10 TB over 5 years. Stateless API service -> Redis cache (hot\n  URLs) -> sharded DB. Base62 encode a unique ID for short codes,\n  CDN for redirect caching, async event stream for analytics.\n- **Real-time chat:** 1:1 and group messaging, presence, history.\n  50M DAU, \u003C200ms delivery, eventual consistency for history. ~500K\n  concurrent connections at peak, ~100K messages\u002Fs. WebSocket\n  gateway sharded by user, message routing service, Cassandra\n  (partitioned by chat_id) for storage, Redis for presence, push\n  notifications for offline users.\n- **Social news feed:** post creation, feed generation, follow\n  relationships. 500M DAU, feed loads \u003C500ms, eventual consistency\n  acceptable. ~10K posts\u002Fs writes, ~500K feed reads\u002Fs. Fan-out on\n  write for users with \u003C10K followers (precompute feeds in Redis),\n  fan-out on read for celebrities (merge at read time). Sharded\n  post storage, feed cache in Redis sorted sets, media in object\n  storage behind a CDN.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Drawing components before gathering requirements.** Starting with boxes and arrows before establishing functional requirements, scale, and consistency needs produces a design that answers \"what architecture looks interesting\" rather than \"what does this system actually need to do.\" Always gather functional requirements and non-functional constraints first; let them determine the components.\n- **Skipping capacity estimation.** A design without back-of-envelope estimates has no basis for claiming it will work at the stated scale. \"We'll add caching if we need it\" is not an architecture — it is a hope. Estimate QPS, storage, and bandwidth before deciding on sharding, caching, or whether a single database will suffice.\n- **Defaulting to strong consistency everywhere.** Most operations in most systems can tolerate eventual consistency, and the cost of strong consistency — coordination overhead, reduced availability, latency — is significant. Defaulting to strong consistency \"to be safe\" means paying that cost unnecessarily. Identify which operations actually require it (financial transactions, inventory decrement) and use eventual consistency for everything else.\n- **Hidden single points of failure.** A design with load-balanced web servers, replicated databases, and a CDN may still have a single point of failure: the database primary, a single cache cluster, or an orchestrator with no failover. Explicitly check every component in the design for what happens if it fails; if the answer is \"everything stops,\" that's a SPOF that needs redundancy.\n- **Premature sharding.** Database sharding adds significant operational complexity: cross-shard queries, resharding when boundaries are wrong, and consistency across shards. Most systems do not need sharding until they are well past what a single well-tuned primary with read replicas can handle. Design for sharding (choose a good shard key) but implement it only when measured data shows the single-node approach is insufficient.\n- **Caching without an invalidation strategy.** Adding a cache without specifying TTL, invalidation triggers, and cache-aside vs write-through strategy means the cache will eventually serve stale data indefinitely. \"We'll figure out invalidation later\" produces a cache that is harmful rather than helpful. Define the invalidation strategy before implementing the cache.\n- **Ignoring the cost of synchronous chains of services.** A request that calls Service A, which calls Service B, which calls Service C in series has a latency that is the sum of all three, and fails if any one of them fails. Beyond two or three hops, this becomes brittle and slow. Identify serial chains in the design and either parallelize calls, pre-compute results asynchronously, or collapse services.\n\n## Full reference\n\n### Powers of 2\n\n| Power | Value | Approx | Common usage |\n|-------|-------|--------|--------------|\n| 2^10  | 1,024 | 1 Thousand | 1 KB |\n| 2^20  | 1,048,576 | 1 Million | 1 MB |\n| 2^30  | 1,073,741,824 | 1 Billion | 1 GB |\n| 2^40  | ~1.1 Trillion | 1 Trillion | 1 TB |\n\nUseful shortcuts: 1 million seconds ~ 12 days. 1 billion seconds ~\n32 years.\n\n### Latency numbers every engineer should know\n\n| Operation | Time |\n|-----------|------|\n| L1 cache reference | 1 ns |\n| L2 cache reference | 4 ns |\n| Main memory reference | 100 ns |\n| Mutex lock\u002Funlock | 17 ns |\n| SSD random read | 16 us |\n| Read 1 MB from memory | 3 us |\n| Read 1 MB sequentially from SSD | 50 us |\n| Read 1 MB sequentially from HDD | 825 us |\n| HDD random read | 2 ms |\n| Round trip within same datacenter | 500 us |\n| Round trip CA to Netherlands | 150 ms |\n\nKey takeaways: memory is ~100x faster than SSD for random access,\nSSD ~100x faster than HDD, intra-DC network ~0.5 ms,\ncross-continent ~150 ms.\n\n### DAU to QPS conversion\n\nFormula: `QPS = DAU * actions_per_user_per_day \u002F 86400`\n\n| DAU  | Actions\u002FUser\u002FDay | QPS (avg) | QPS (peak, 3x) |\n|------|------------------|-----------|----------------|\n| 1M   | 10               | ~115      | ~350           |\n| 10M  | 10               | ~1,150    | ~3,500         |\n| 100M | 10               | ~11,500   | ~35,000        |\n| 1B   | 10               | ~115,000  | ~350,000       |\n\nRule of thumb: 1M DAU * 10 actions\u002Fday ~ 100 QPS average, 300-500\nQPS peak.\n\n### Storage estimation\n\n| Data type | Typical size |\n|-----------|--------------|\n| User profile (text) | 1-5 KB |\n| Tweet \u002F short post | 250 B - 1 KB |\n| Chat message | 100-500 B |\n| Photo (compressed) | 200 KB - 2 MB |\n| Video (1 min, compressed) | 5-50 MB |\n| Log entry | 200-500 B |\n| DB row (typical) | 500 B - 2 KB |\n\nFormula: `total = records_per_day * avg_size * retention_days`.\nExample: 10M messages\u002Fday * 500 bytes * 365 days * 5 years ~ 9 TB.\n\n### Bandwidth\n\nFormula: `bandwidth = QPS * avg_size`. Example: 10K QPS * 5 KB\naverage response = 50 MB\u002Fs = 400 Mbps outbound.\n\n### Common capacity patterns\n\n- **1M DAU social app:** ~100 QPS avg, ~500 QPS peak. ~10 GB\u002Fday\n  new data. ~5 TB over 2 years. 2-5 app servers, 1-2 DB servers,\n  Redis cache.\n- **100M DAU messaging app:** ~50K QPS avg, ~200K QPS peak. ~500\n  GB\u002Fday messages. ~500 TB over 3 years. Sharded DB cluster,\n  dedicated cache layer, WebSocket gateway fleet.\n- **1B DAU read-heavy platform:** ~500K QPS avg, ~2M QPS peak.\n  Multi-region CDN mandatory. Read replicas plus 95%+ cache hit\n  rate. Terabytes of bandwidth per day.\n\n### Server capacity rules of thumb\n\n| Resource | Typical limit |\n|----------|---------------|\n| Single web server (simple API) | 1K-10K QPS |\n| Single Redis instance | 100K+ ops\u002Fs |\n| Single PostgreSQL (tuned) | 5K-20K QPS |\n| Single Kafka broker | 100K+ messages\u002Fs |\n| Single machine network | 1-10 Gbps |\n| Single machine connections | 10K-100K concurrent |\n\n### Quick estimation framework\n\n1. Start with DAU and read:write ratio.\n2. Compute average and peak QPS.\n3. Estimate storage per year.\n4. Estimate bandwidth (QPS * size).\n5. Divide QPS by per-server capacity to get instance count.\n6. Add 2-3x headroom for growth and spikes.\n7. Consider geographic distribution needs.\n\n### Anti-patterns\n\n- **Drawing boxes before requirements** — leads to designs that\n  solve the wrong problem.\n- **Skipping estimation** — \"we'll scale when we get there\" usually\n  means the design cannot.\n- **Picking strong consistency by default** — most systems can\n  tolerate eventual consistency for most operations, and the cost\n  of strong consistency is high.\n- **Single point of failure hidden in plain sight** — usually the\n  database, the load balancer, or a \"smart\" orchestrator.\n- **Caching without invalidation strategy** — stale reads outlive\n  the bug that introduced them.\n- **Premature sharding** — shard when you have to, not before. The\n  operational cost is real.\n- **Synchronous chains of more than 2-3 services** — latency\n  multiplies and any one failure takes the chain down.\n","# System Design\n\n## Intro\n\nSystem design starts with requirements, not boxes. Estimate capacity\non the back of an envelope, draw a small high-level architecture,\nthen deep-dive only the components that are unique or risky. Make\ntrade-offs explicit — every design decision has a cost.\n\n## Overview\n\n### Gather requirements\n\nAlways start with requirements. Split them into functional and\nnon-functional.\n\n**Functional:** what does the system do? Core use cases (2-4 most\nimportant), user-facing vs internal features, data formats, and key\nend-to-end workflows.\n\n**Non-functional:** how well must it do it?\n\n- **Scale** — DAU, peak QPS, data volume\n- **Latency** — p50 and p99 targets\n- **Availability** — 99.9%, 99.99%, or higher (and the downtime\n  budget that implies)\n- **Consistency** — strong or eventual, and which parts need which\n- **Durability** — RPO\u002FRTO targets, can we lose data\n- **Security** — auth, encryption, compliance constraints\n- **Cost** — budget, managed vs self-hosted preference\n\nDo not over-specify. Focus on what differentiates this system from a\ngeneric CRUD app.\n\n### Capacity estimation\n\nNumbers and formulas live in `references\u002Festimation-cheatsheet.md`.\n\nBack-of-envelope framework:\n\n1. **Users** — DAU -> peak concurrent -> requests per second\n2. **Storage** — data per record * records per day * retention\n3. **Bandwidth** — request size * QPS in + response size * QPS out\n4. **Compute** — QPS \u002F requests-per-instance = instance count\n\nState assumptions explicitly: read:write ratio (most systems are\n10:1 to 100:1), peak-to-average ratio (typically 3x-10x), data\ngrowth rate (linear or exponential), and cache hit rate (often\n80-95% for read-heavy workloads).\n\n### High-level design\n\nDraw 5-10 major components. Start with the client and work inward.\nFor each core use case, trace the data flow with numbered arrows.\nPlace standard infrastructure where it belongs: load balancer, API\ngateway, CDN, cache, database, queue. For each kind of data, choose\na store (relational, document, blob, cache, search index). Keep it\nsimple first; add complexity only when requirements demand it.\n\n### Component deep dives\n\nFor each critical component, detail:\n\n- **API design** — endpoints, request\u002Fresponse formats, pagination\n- **Data model** — schema, indexing, partitioning\u002Fsharding key\n- **Scaling strategy** — horizontal vs vertical, stateless vs\n  stateful\n- **Failure handling** — what happens when this component dies\n- **Caching** — what is cached, where (client, CDN, app, DB), TTL,\n  invalidation\n\nFocus deep dives on components that are unique to this system or\nmost likely to be bottlenecks. Don't deep-dive a stock load\nbalancer.\n\n### Trade-off analysis\n\nEvery decision has trade-offs. State the side you chose and why,\ngiven the requirements:\n\n- **Consistency vs availability** — CAP theorem; in a partition you\n  pick C or A\n- **Latency vs throughput** — batching raises throughput at the cost\n  of latency\n- **Simplicity vs scalability** — simpler designs are easier to\n  operate but may not scale\n- **Cost vs performance** — caching reduces latency but raises\n  infrastructure cost\n- **Flexibility vs optimization** — denormalization speeds reads but\n  complicates writes\n\n### Scalability patterns\n\n- **Horizontal scaling** — stateless services behind a load balancer\n- **Database sharding** — partition by user ID, tenant ID, or region\n- **Read replicas** — offload reads, accept replication lag\n- **Caching layers** — local cache -> distributed cache (Redis) ->\n  CDN\n- **Async processing** — push non-critical work onto background\n  queues\n- **Event-driven decoupling** — pub\u002Fsub between producers and\n  consumers\n- **Rate limiting** — token bucket, sliding window\n- **Circuit breakers** — prevent cascade failures when downstream is\n  unhealthy\n\n### Example workflows\n\n- **URL shortener:** create \u002F redirect \u002F analytics. 100M URLs\u002Fmonth,\n  \u003C100ms redirect, 99.99% availability. ~40 writes\u002Fs, ~4000 reads\u002Fs,\n  ~10 TB over 5 years. Stateless API service -> Redis cache (hot\n  URLs) -> sharded DB. Base62 encode a unique ID for short codes,\n  CDN for redirect caching, async event stream for analytics.\n- **Real-time chat:** 1:1 and group messaging, presence, history.\n  50M DAU, \u003C200ms delivery, eventual consistency for history. ~500K\n  concurrent connections at peak, ~100K messages\u002Fs. WebSocket\n  gateway sharded by user, message routing service, Cassandra\n  (partitioned by chat_id) for storage, Redis for presence, push\n  notifications for offline users.\n- **Social news feed:** post creation, feed generation, follow\n  relationships. 500M DAU, feed loads \u003C500ms, eventual consistency\n  acceptable. ~10K posts\u002Fs writes, ~500K feed reads\u002Fs. Fan-out on\n  write for users with \u003C10K followers (precompute feeds in Redis),\n  fan-out on read for celebrities (merge at read time). Sharded\n  post storage, feed cache in Redis sorted sets, media in object\n  storage behind a CDN.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Drawing components before gathering requirements.** Starting with boxes and arrows before establishing functional requirements, scale, and consistency needs produces a design that answers \"what architecture looks interesting\" rather than \"what does this system actually need to do.\" Always gather functional requirements and non-functional constraints first; let them determine the components.\n- **Skipping capacity estimation.** A design without back-of-envelope estimates has no basis for claiming it will work at the stated scale. \"We'll add caching if we need it\" is not an architecture — it is a hope. Estimate QPS, storage, and bandwidth before deciding on sharding, caching, or whether a single database will suffice.\n- **Defaulting to strong consistency everywhere.** Most operations in most systems can tolerate eventual consistency, and the cost of strong consistency — coordination overhead, reduced availability, latency — is significant. Defaulting to strong consistency \"to be safe\" means paying that cost unnecessarily. Identify which operations actually require it (financial transactions, inventory decrement) and use eventual consistency for everything else.\n- **Hidden single points of failure.** A design with load-balanced web servers, replicated databases, and a CDN may still have a single point of failure: the database primary, a single cache cluster, or an orchestrator with no failover. Explicitly check every component in the design for what happens if it fails; if the answer is \"everything stops,\" that's a SPOF that needs redundancy.\n- **Premature sharding.** Database sharding adds significant operational complexity: cross-shard queries, resharding when boundaries are wrong, and consistency across shards. Most systems do not need sharding until they are well past what a single well-tuned primary with read replicas can handle. Design for sharding (choose a good shard key) but implement it only when measured data shows the single-node approach is insufficient.\n- **Caching without an invalidation strategy.** Adding a cache without specifying TTL, invalidation triggers, and cache-aside vs write-through strategy means the cache will eventually serve stale data indefinitely. \"We'll figure out invalidation later\" produces a cache that is harmful rather than helpful. Define the invalidation strategy before implementing the cache.\n- **Ignoring the cost of synchronous chains of services.** A request that calls Service A, which calls Service B, which calls Service C in series has a latency that is the sum of all three, and fails if any one of them fails. Beyond two or three hops, this becomes brittle and slow. Identify serial chains in the design and either parallelize calls, pre-compute results asynchronously, or collapse services.\n\n## Full reference\n\n### Powers of 2\n\n| Power | Value | Approx | Common usage |\n|-------|-------|--------|--------------|\n| 2^10  | 1,024 | 1 Thousand | 1 KB |\n| 2^20  | 1,048,576 | 1 Million | 1 MB |\n| 2^30  | 1,073,741,824 | 1 Billion | 1 GB |\n| 2^40  | ~1.1 Trillion | 1 Trillion | 1 TB |\n\nUseful shortcuts: 1 million seconds ~ 12 days. 1 billion seconds ~\n32 years.\n\n### Latency numbers every engineer should know\n\n| Operation | Time |\n|-----------|------|\n| L1 cache reference | 1 ns |\n| L2 cache reference | 4 ns |\n| Main memory reference | 100 ns |\n| Mutex lock\u002Funlock | 17 ns |\n| SSD random read | 16 us |\n| Read 1 MB from memory | 3 us |\n| Read 1 MB sequentially from SSD | 50 us |\n| Read 1 MB sequentially from HDD | 825 us |\n| HDD random read | 2 ms |\n| Round trip within same datacenter | 500 us |\n| Round trip CA to Netherlands | 150 ms |\n\nKey takeaways: memory is ~100x faster than SSD for random access,\nSSD ~100x faster than HDD, intra-DC network ~0.5 ms,\ncross-continent ~150 ms.\n\n### DAU to QPS conversion\n\nFormula: `QPS = DAU * actions_per_user_per_day \u002F 86400`\n\n| DAU  | Actions\u002FUser\u002FDay | QPS (avg) | QPS (peak, 3x) |\n|------|------------------|-----------|----------------|\n| 1M   | 10               | ~115      | ~350           |\n| 10M  | 10               | ~1,150    | ~3,500         |\n| 100M | 10               | ~11,500   | ~35,000        |\n| 1B   | 10               | ~115,000  | ~350,000       |\n\nRule of thumb: 1M DAU * 10 actions\u002Fday ~ 100 QPS average, 300-500\nQPS peak.\n\n### Storage estimation\n\n| Data type | Typical size |\n|-----------|--------------|\n| User profile (text) | 1-5 KB |\n| Tweet \u002F short post | 250 B - 1 KB |\n| Chat message | 100-500 B |\n| Photo (compressed) | 200 KB - 2 MB |\n| Video (1 min, compressed) | 5-50 MB |\n| Log entry | 200-500 B |\n| DB row (typical) | 500 B - 2 KB |\n\nFormula: `total = records_per_day * avg_size * retention_days`.\nExample: 10M messages\u002Fday * 500 bytes * 365 days * 5 years ~ 9 TB.\n\n### Bandwidth\n\nFormula: `bandwidth = QPS * avg_size`. Example: 10K QPS * 5 KB\naverage response = 50 MB\u002Fs = 400 Mbps outbound.\n\n### Common capacity patterns\n\n- **1M DAU social app:** ~100 QPS avg, ~500 QPS peak. ~10 GB\u002Fday\n  new data. ~5 TB over 2 years. 2-5 app servers, 1-2 DB servers,\n  Redis cache.\n- **100M DAU messaging app:** ~50K QPS avg, ~200K QPS peak. ~500\n  GB\u002Fday messages. ~500 TB over 3 years. Sharded DB cluster,\n  dedicated cache layer, WebSocket gateway fleet.\n- **1B DAU read-heavy platform:** ~500K QPS avg, ~2M QPS peak.\n  Multi-region CDN mandatory. Read replicas plus 95%+ cache hit\n  rate. Terabytes of bandwidth per day.\n\n### Server capacity rules of thumb\n\n| Resource | Typical limit |\n|----------|---------------|\n| Single web server (simple API) | 1K-10K QPS |\n| Single Redis instance | 100K+ ops\u002Fs |\n| Single PostgreSQL (tuned) | 5K-20K QPS |\n| Single Kafka broker | 100K+ messages\u002Fs |\n| Single machine network | 1-10 Gbps |\n| Single machine connections | 10K-100K concurrent |\n\n### Quick estimation framework\n\n1. Start with DAU and read:write ratio.\n2. Compute average and peak QPS.\n3. Estimate storage per year.\n4. Estimate bandwidth (QPS * size).\n5. Divide QPS by per-server capacity to get instance count.\n6. Add 2-3x headroom for growth and spikes.\n7. Consider geographic distribution needs.\n\n### Anti-patterns\n\n- **Drawing boxes before requirements** — leads to designs that\n  solve the wrong problem.\n- **Skipping estimation** — \"we'll scale when we get there\" usually\n  means the design cannot.\n- **Picking strong consistency by default** — most systems can\n  tolerate eventual consistency for most operations, and the cost\n  of strong consistency is high.\n- **Single point of failure hidden in plain sight** — usually the\n  database, the load balancer, or a \"smart\" orchestrator.\n- **Caching without invalidation strategy** — stale reads outlive\n  the bug that introduced them.\n- **Premature sharding** — shard when you have to, not before. The\n  operational cost is real.\n- **Synchronous chains of more than 2-3 services** — latency\n  multiplies and any one failure takes the chain down.\n",{"name":5,"metadata":53,"description":60},{"processkit":54},{"id":55,"created":56,"version":57,"category":58,"apiVersion":59},"SKILL-system-design",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","System design methodology — requirements, capacity estimation, component design, trade-offs. Use when designing a new distributed system, evaluating an existing architecture for scalability or cost, performing back-of-envelope capacity estimation, or preparing for a system design review.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.13.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fsystem-design","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add projectious-work\u002Fprocesskit --skill system-design",{"tool":74,"command":75},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill system-design",{"tool":77,"command":78},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill system-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.13.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fsystem-design\u002FSKILL.md",true,[82],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Festimation-cheatsheet.md","REFERENCE","参考文档",3452,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.13.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fsystem-design\u002Freferences\u002Festimation-cheatsheet.md",[89,113,133,154,171,189],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":98,"publishedAt":48},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[95],{"categoryNo":96,"categoryName":97,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[99,100,101,102,103,104,41,105,106,107,91,108,109,110,36,111,112],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":48},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[119],{"categoryNo":96,"categoryName":97,"taxonomyType":21,"taxonomyTypeDesc":22},[99,121,122,123,124,125,104,41,126,127,106,128,129,130,108,131,132],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":48},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[99,140,141,101,102,142,104,41,143,144,145,146,108,147,148,149,150,151,152,153],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":48},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[99,107,161,101,104,162,163,126,164,143,106,165,166,108,167,168,148,169,36,170],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":48},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[178,179,180,181,104,182,183,184,41,185,186,187,188],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":48},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[99,196,197,101,102,142,104,162,41,105,143,198,106,145,108,168,148,149,199,112],"capability","capability management","queries","changes"]