[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B6EYN524WJM12A67ASYHS":3,"skill-same:01M69B6EYN524WJM12A67ASYHS":55},{"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":21,"linkOnly":22,"markdownContent":23,"markdownBody":24,"frontMatter":25,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M69B6EYN524WJM12A67ASYHS","tradeoff-analysis",null,"Structured tradeoff analysis methodology — the 8-dimension comparison frame, tradeoff matrix template, and common tradeoff patterns. Use when evaluating design alternatives, comparing technology choices, or when the answer is 'it depends.'","microsoft\u002Famplifier-bundle-systems-design","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69B51GBR7WTZ199PCPYGB6S",5,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Ftradeoff-analysis\u002FSKILL.md",[],[19,20],"tradeoff analysis","design","2026-11-10 10:12:30",false,"---\nname: tradeoff-analysis\ndescription: \"Structured tradeoff analysis methodology — the 8-dimension comparison frame, tradeoff matrix template, and common tradeoff patterns. Use when evaluating design alternatives, comparing technology choices, or when the answer is 'it depends.'\"\n---\n\n# Tradeoff Analysis\n\n## The Central Question\n\nEvery design decision answers this:\n\n> **\"What does this optimize for, and what does it sacrifice?\"**\n\nIf you cannot answer this clearly for a design, the design is not yet understood.\n\n## The 8-Dimension Comparison Frame\n\nEvaluate every design alternative against these fixed dimensions. Do not invent new dimensions — force the analysis into this frame so alternatives are comparable.\n\n| Dimension | Key Question | Watch For |\n|-----------|-------------|-----------|\n| **Latency** | How fast must it respond? | P50 vs P99 distinction; latency budgets per hop |\n| **Complexity** | How many concepts must be held in mind? | Operational complexity vs code complexity — they diverge |\n| **Reliability** | What is the acceptable failure rate? | Partial degradation vs total failure; blast radius |\n| **Cost** | What are the resource costs now and at scale? | Cost curves that are linear now but exponential later |\n| **Security** | What is the attack surface? | Authentication, authorization, data exposure, supply chain |\n| **Scalability** | What grows with usage, time, and org size? | The thing that scales worst is the bottleneck |\n| **Reversibility** | How hard is it to undo this decision? | Data model choices are least reversible; API contracts are hard; implementation details are easy |\n| **Organizational fit** | Does this match the team's actual ability? | A design the team cannot operate is a failed design |\n\n## Tradeoff Matrix Template\n\nFor comparing N alternatives, fill this matrix:\n\n| Dimension | Option A | Option B | Option C |\n|-----------|----------|----------|----------|\n| Latency | [rating + note] | [rating + note] | [rating + note] |\n| Complexity | ... | ... | ... |\n| Reliability | ... | ... | ... |\n| Cost | ... | ... | ... |\n| Security | ... | ... | ... |\n| Scalability | ... | ... | ... |\n| Reversibility | ... | ... | ... |\n| Org fit | ... | ... | ... |\n| **Optimizes for** | [1-line summary] | [1-line summary] | [1-line summary] |\n| **Sacrifices** | [1-line summary] | [1-line summary] | [1-line summary] |\n\nRatings: use qualitative assessments (good\u002Fadequate\u002Fpoor) with a concrete note explaining why. Numeric scores create false precision.\n\n## Common Tradeoff Patterns\n\nThese pairs recur across system design. Recognizing the pattern accelerates analysis.\n\n**Consistency vs. Availability** — CAP theorem and its practical implications. Strong consistency requires coordination; eventual consistency allows independent operation. Most systems need consistency for some data and availability for other data — the design question is where to draw the line.\n\n**Simplicity vs. Flexibility** — Simple systems are easy to understand but hard to extend. Flexible systems handle change but are harder to reason about. Prefer simplicity unless you have concrete evidence that flexibility will be needed — not hypothetical future requirements.\n\n**Latency vs. Throughput** — Optimizing for individual request speed often reduces total system throughput (and vice versa). Batching improves throughput but hurts latency. Streaming can sometimes improve both.\n\n**Build vs. Buy** — Building gives control and fit; buying gives speed and maintained infrastructure. The hidden cost of \"buy\" is operational dependency. The hidden cost of \"build\" is maintenance burden.\n\n**Centralization vs. Distribution** — Centralized systems are simpler to reason about but create single points of failure and scaling bottlenecks. Distributed systems are resilient but introduce coordination complexity.\n\n**Optimization vs. Observability** — Aggressive optimization (caching, denormalization, precomputation) makes systems faster but harder to debug. Ensure every optimization comes with the monitoring needed to verify it works.\n\n**Safety vs. Speed** — Guardrails (validation, type checking, review processes) slow development but prevent failures. The cost of skipping them is paid later, with interest.\n\n**Present Cost vs. Future Cost** — Technical debt is borrowing from the future. Sometimes that's the right tradeoff — but name it explicitly and track the repayment plan.\n\n## How to Use This Framework\n\n1. **Identify the alternatives.** If you have fewer than 2, you haven't explored enough. If you have more than 5, narrow first.\n2. **Fill the matrix.** Force every cell to have a rating and a note. Empty cells mean unexamined risk.\n3. **Identify the dominant tradeoff.** Which 1-2 dimensions most differentiate the options? That is where the real decision lies.\n4. **State what you are sacrificing.** The recommendation is incomplete without this.\n5. **Ask: \"What would have to be true for this to be the wrong choice?\"** This is the most powerful question in tradeoff analysis. It surfaces hidden assumptions and identifies monitoring signals.\n","# Tradeoff Analysis\n\n## The Central Question\n\nEvery design decision answers this:\n\n> **\"What does this optimize for, and what does it sacrifice?\"**\n\nIf you cannot answer this clearly for a design, the design is not yet understood.\n\n## The 8-Dimension Comparison Frame\n\nEvaluate every design alternative against these fixed dimensions. Do not invent new dimensions — force the analysis into this frame so alternatives are comparable.\n\n| Dimension | Key Question | Watch For |\n|-----------|-------------|-----------|\n| **Latency** | How fast must it respond? | P50 vs P99 distinction; latency budgets per hop |\n| **Complexity** | How many concepts must be held in mind? | Operational complexity vs code complexity — they diverge |\n| **Reliability** | What is the acceptable failure rate? | Partial degradation vs total failure; blast radius |\n| **Cost** | What are the resource costs now and at scale? | Cost curves that are linear now but exponential later |\n| **Security** | What is the attack surface? | Authentication, authorization, data exposure, supply chain |\n| **Scalability** | What grows with usage, time, and org size? | The thing that scales worst is the bottleneck |\n| **Reversibility** | How hard is it to undo this decision? | Data model choices are least reversible; API contracts are hard; implementation details are easy |\n| **Organizational fit** | Does this match the team's actual ability? | A design the team cannot operate is a failed design |\n\n## Tradeoff Matrix Template\n\nFor comparing N alternatives, fill this matrix:\n\n| Dimension | Option A | Option B | Option C |\n|-----------|----------|----------|----------|\n| Latency | [rating + note] | [rating + note] | [rating + note] |\n| Complexity | ... | ... | ... |\n| Reliability | ... | ... | ... |\n| Cost | ... | ... | ... |\n| Security | ... | ... | ... |\n| Scalability | ... | ... | ... |\n| Reversibility | ... | ... | ... |\n| Org fit | ... | ... | ... |\n| **Optimizes for** | [1-line summary] | [1-line summary] | [1-line summary] |\n| **Sacrifices** | [1-line summary] | [1-line summary] | [1-line summary] |\n\nRatings: use qualitative assessments (good\u002Fadequate\u002Fpoor) with a concrete note explaining why. Numeric scores create false precision.\n\n## Common Tradeoff Patterns\n\nThese pairs recur across system design. Recognizing the pattern accelerates analysis.\n\n**Consistency vs. Availability** — CAP theorem and its practical implications. Strong consistency requires coordination; eventual consistency allows independent operation. Most systems need consistency for some data and availability for other data — the design question is where to draw the line.\n\n**Simplicity vs. Flexibility** — Simple systems are easy to understand but hard to extend. Flexible systems handle change but are harder to reason about. Prefer simplicity unless you have concrete evidence that flexibility will be needed — not hypothetical future requirements.\n\n**Latency vs. Throughput** — Optimizing for individual request speed often reduces total system throughput (and vice versa). Batching improves throughput but hurts latency. Streaming can sometimes improve both.\n\n**Build vs. Buy** — Building gives control and fit; buying gives speed and maintained infrastructure. The hidden cost of \"buy\" is operational dependency. The hidden cost of \"build\" is maintenance burden.\n\n**Centralization vs. Distribution** — Centralized systems are simpler to reason about but create single points of failure and scaling bottlenecks. Distributed systems are resilient but introduce coordination complexity.\n\n**Optimization vs. Observability** — Aggressive optimization (caching, denormalization, precomputation) makes systems faster but harder to debug. Ensure every optimization comes with the monitoring needed to verify it works.\n\n**Safety vs. Speed** — Guardrails (validation, type checking, review processes) slow development but prevent failures. The cost of skipping them is paid later, with interest.\n\n**Present Cost vs. Future Cost** — Technical debt is borrowing from the future. Sometimes that's the right tradeoff — but name it explicitly and track the repayment plan.\n\n## How to Use This Framework\n\n1. **Identify the alternatives.** If you have fewer than 2, you haven't explored enough. If you have more than 5, narrow first.\n2. **Fill the matrix.** Force every cell to have a rating and a note. Empty cells mean unexamined risk.\n3. **Identify the dominant tradeoff.** Which 1-2 dimensions most differentiate the options? That is where the real decision lies.\n4. **State what you are sacrificing.** The recommendation is incomplete without this.\n5. **Ask: \"What would have to be true for this to be the wrong choice?\"** This is the most powerful question in tradeoff analysis. It surfaces hidden assumptions and identifies monitoring signals.\n",{"name":5,"description":7},"main","1eff6a2bcebe7c42d5d8d4962e1937a3bb932b0c","skills\u002Ftradeoff-analysis",2,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-05-18 08:17:41",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add microsoft\u002Famplifier-bundle-systems-design --skill tradeoff-analysis",{"tool":41,"command":42},"bunx","bunx skills add microsoft\u002Famplifier-bundle-systems-design --skill tradeoff-analysis",{"tool":44,"command":45},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-bundle-systems-design --skill tradeoff-analysis","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Ftradeoff-analysis\u002FSKILL.md",true,[49],{"path":50,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":54},"scripts\u002Fomake.sh","SCRIPT","脚本",2010,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fimpala\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fbuild-one-cc-file\u002Fscripts\u002Fomake.sh",[56,76,87,100,111,124],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":72,"publishedAt":21},"01M69B6DE6YFEZS2D8RWSFPAVC","systems-design-review-methodology","Use when the \u002Fsystems-design-review mode is active. 7-step design review methodology -- understand the design, classify the system, evaluate against codebase, adversarial analysis, tradeoff validation, synthesis, and action items. Governs conversation flow, delegation patterns, and user validation checkpoints.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Fsystems-design-review-methodology\u002FSKILL.md",[62,67],{"categoryNo":63,"categoryName":64,"taxonomyType":65,"taxonomyTypeDesc":66},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[73,74,75,20],"systems design review methodology","design review","review",{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":84,"publishedAt":21},"01M69B6BG8XVGB2QMNFKFYBZVX","systems-design-methodology","Use when the \u002Fsystems-design mode is active. 9-phase structured design methodology -- problem framing, system classification, constraints, candidate architectures, tradeoff analysis, risk review, refinement, migration planning, and documentation. Governs conversation flow, delegation patterns, and user validation checkpoints.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Fsystems-design-methodology\u002FSKILL.md",[82,83],{"categoryNo":63,"categoryName":64,"taxonomyType":65,"taxonomyTypeDesc":66},{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},[85,20,75,86],"systems design methodology","documentation",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":96,"publishedAt":21},"01M69B69R21TMX6E7WVH241YW7","system-type-workflow-orchestration","Domain patterns for workflow orchestration systems — long-running processes, state machines, saga coordination, human-in-the-loop gates, retry and timeout hierarchies, and failure modes. Use when designing or evaluating workflow engines, job orchestrators, or multi-step business process systems.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Fsystem-type-workflow-orchestration\u002FSKILL.md",[93],{"categoryNo":94,"categoryName":95,"taxonomyType":65,"taxonomyTypeDesc":66},"01JBSEEDCAT000000000000023","Skill与智能体开发",[97,98,99],"system type workflow orchestration","workflow","orchestration",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":21},"01M69B67T9XSXZFZMS8BA8XTN4","system-type-web-service","Domain patterns for web service architecture — API design (REST\u002FGraphQL\u002FgRPC), scaling, data layer, observability, failure modes, and anti-patterns. Use when designing or evaluating a web service, API, or request\u002Fresponse system.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Fsystem-type-web-service\u002FSKILL.md",[],[107,108,109,110,20],"system type web service","web","api design","architecture",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":120,"publishedAt":21},"01M69B6478TS22P136B0N54HJX","system-type-spa","Domain patterns for single-page application architecture — client-side routing, state management, rendering strategies, authentication, performance, and offline support. Use when designing or evaluating a browser-based SPA, progressive web app, or rich client-side application.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Fsystem-type-spa\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":65,"taxonomyTypeDesc":66},"01JBSEEDCAT000000000000009","前端开发",[121,110,108,122,123],"system type spa","support","performance",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":21},"01M69B62JJKQ2XRD5ZW0RW33KT","system-type-real-time","Domain patterns for real-time and collaborative systems — persistent connections, state synchronization, conflict resolution, presence, fan-out, and failure modes. Use when designing or evaluating chat systems, collaborative editors, live dashboards, gaming backends, or any system with bidirectional real-time communication.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Fblob\u002Fmain\u002Fskills\u002Fsystem-type-real-time\u002FSKILL.md",[],[131,132],"real time","system type real time"]