$ loading_
Domain patterns for Azure cloud architecture — compute selection, managed services, identity (Entra ID), networking, data platform, messaging, deployment, cost management, and operational patterns. Use when designing or evaluating a system deployed on Microsoft Azure.
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "system-type-azure" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/system-type-azure/SKILL.md 2. 保存为 ~/.claude/skills/system-type-azure/SKILL.md 3. 装好后重载技能，告诉我可以用了
Patterns, failure modes, and anti-patterns for systems built on Microsoft Azure.
When to use. Web applications, REST APIs, and backend services where you want managed infrastructure with zero Kubernetes overhead. Supports .NET, Java, Node.js, Python, Go. Built-in autoscaling, deployment slots, and custom domains with managed TLS. When to avoid. Workloads that need GPU, custom networking at the host level, or containers with sidecar patterns. When per-second billing matters (App Service charges per plan, not per request). Workloads that need sub-second cold start. Key decisions. Plan tier (Free/Basic for dev, Standard/Premium for production — Premium required for VNet integration and deployment slots), Linux vs Windows, scaling rules (CPU, memory, HTTP queue length, custom metrics), always-on setting (prevents cold starts on Standard+), deployment slot swap strategy.
When to use. Event-driven, short-lived compute — HTTP triggers, queue processors, timer-based jobs, event hub consumers. Consumption plan gives true pay-per-execution. Ideal for glue logic, webhooks, and lightweight APIs. When to avoid. Long-running processes (Consumption plan has a 5/10-minute timeout). Workloads with sustained high throughput (Consumption plan cold starts add latency; Premium or Dedicated plan negates the cost advantage). Complex orchestration (use Durable Functions or Container Apps instead). Key decisions. Hosting plan (Consumption for sporadic traffic, Premium for VNet and pre-warmed instances, Dedicated for predictable load), runtime version, trigger binding selection, Durable Functions for orchestration/fan-out, function app isolation boundaries (one app per domain concern).
When to use. Containerized microservices and APIs when you want Kubernetes-like capabilities (scaling, Dapr, service discovery, revisions) without managing a cluster. Built on Kubernetes but abstracts it away. Supports scale-to-zero. When to avoid. When you need full Kubernetes control (custom operators, CRDs, node-level config). Workloads requiring GPU. When the team has deep Kubernetes expertise and the abstraction layer gets in the way. Key decisions. Environment design (shared environments for related services, separate for isolation), Dapr sidecar usage (service invocation, state, pub/sub), scaling rules (HTTP concurrency, KEDA scalers for queues/events), revision management, ingress configuration (internal vs external).
When to use. Complex containerized workloads that need full Kubernetes control — custom operators, advanced scheduling, node pools with specific hardware (GPU, high-memory), tight integration with the Kubernetes ecosystem. When the team has Kubernetes expertise. When to avoid. Simple web apps or APIs (App Service or Container Apps are simpler). Small teams without Kubernetes experience — the operational burden is significant. When the Kubernetes features you'd use are already available in Container Apps. Key decisions. Node pool strategy (system vs user pools, spot instances for batch), networking model (kubenet vs Azure CNI — CNI required for VNet pod-level networking), cluster autoscaler vs KEDA, managed identity for pod identity (Workload Identity), upgrade strategy (blue-green node pools vs rolling), monitoring (Container Insights, Prometheus).
When to use. Workloads that need full OS control — legacy applications, license-constrained software (BYOL), custom kernel requirements, GPU workloads not supported by higher-level services. Lift-and-shift migrations. When to avoid. Greenfield applications where managed services exist. Any workload where you'd be building infrastructure that Azure already provides (load balancing, auto-restart, scaling, patching).
…
Catalog of reusable architectural primitives — boundaries, contracts, state machines, queues, caches, consistency models, and more. For each: what it is, when it's right, when it's WRONG. Use when selecting patterns for a design or evaluating whether a pattern fits.
Domain-Driven Design as a lens for system architecture — bounded contexts, aggregates, ubiquitous language, context mapping, domain events, and strategic vs tactical patterns. Use when modeling complex business domains, defining service boundaries, or evaluating whether a system's structure reflects its domain.
The Unix/Linux design philosophy as a lens for system design — mechanism vs policy, composability, small tools, text streams, convention over configuration, and the principle of least surprise. Use when evaluating designs for composability, simplicity, or separation of concerns.
Object-oriented design principles as a lens for system architecture — SOLID, composition over inheritance, the actor model, design patterns (and when they're wrong), encapsulation, polymorphism, and responsibility-driven design. Use when evaluating code organization, module boundaries, or object/component relationships.
Domain patterns for CLI tools and developer SDKs — command structure, configuration layering, plugin architecture, distribution, backward compatibility, shell integration, and failure modes. Use when designing or evaluating command-line tools, developer platforms, or SDK libraries.
Adversarial review of a system design from 6 critical perspectives -- SRE, security, staff engineer, finance, operator, and developer advocate. Produces a unified risk assessment. Use for INTERACTIVE on-demand reviews during a design conversation (/adversarial-review). For RECIPE-DRIVEN reviews (where prior step context is needed), use the systems-design-critic agent instead.