// 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.
Use when the /systems-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.
Use when the /systems-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.
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.
Domain patterns for peer-to-peer system architecture — network topologies, NAT traversal, peer discovery, data distribution, consistency without central authority, identity and trust, and incentive mechanisms. Use when designing or evaluating a decentralized, peer-to-peer, or mesh-networked system.
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.
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.
| name | system-type-azure |
| description | 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. |
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). Key decisions. VM series selection (B-series for burstable, D-series general purpose, E-series memory, N-series GPU), managed disks (Premium SSD for production), availability sets vs availability zones, VM Scale Sets for autoscaling, Azure Bastion for secure access (no public SSH), image management (Azure Image Builder, Shared Image Gallery).
When to use. Always. Entra ID is the identity control plane for Azure. Every Azure workload should authenticate via Entra ID — user authentication, service-to-service, and resource access. It's not optional; it's the foundation. When to avoid. Never for Azure workloads. For non-Azure external systems that can't speak OIDC/SAML, use Entra ID as the authority and bridge with appropriate protocols. Key decisions. Tenant architecture (single vs multi-tenant), app registration model (one per service vs shared), permission model (delegated vs application permissions), Conditional Access policies, token lifetime and caching, B2C vs B2B for external identities.
When to use. Any Azure resource that needs to call another Azure resource or Entra ID-protected API. Managed Identity eliminates stored credentials — Azure handles the certificate rotation and token acquisition. System-assigned for single-resource lifecycle, user-assigned for shared identity across resources. When to avoid. Never, when the alternative is storing secrets. If an Azure service supports Managed Identity, use it. The only exception is when calling third-party APIs that don't support Entra ID tokens. Key decisions. System-assigned vs user-assigned (user-assigned enables shared identity and survives resource recreation), RBAC role assignments (least privilege — never Contributor when Reader suffices), DefaultAzureCredential chain for code that runs both locally and in Azure.
When to use. All authorization decisions for Azure resource access. RBAC controls who can do what to which resources. Assign roles at the narrowest scope possible — resource, resource group, subscription. When to avoid. Application-level authorization (RBAC controls Azure resources, not your app's business logic — use application-level roles or Entra ID app roles for that). Key decisions. Custom roles vs built-in roles (prefer built-in), role assignment scope (resource group is the common sweet spot), PIM (Privileged Identity Management) for just-in-time elevation, deny assignments for guardrails, regular access reviews.
When to use. Storing secrets, certificates, and encryption keys that can't use Managed Identity (third-party API keys, connection strings for non-Azure services, TLS certificates). Central secret management with audit logging. When to avoid. Secrets that could be eliminated by using Managed Identity instead. High-throughput crypto operations that need HSM-level performance (use Managed HSM or Dedicated HSM). Key decisions. Vault-per-environment (dev/staging/prod), access policy model (RBAC is preferred over vault access policies), secret rotation strategy, soft-delete and purge protection (enable both in production — data loss prevention), network restrictions (private endpoint for production vaults).
When to use. All production workloads. VNet is the network isolation boundary in Azure. Every VM, AKS cluster, App Service (with VNet integration), and database (with private endpoint) should be inside a VNet. When to avoid. Only for quick prototypes or development environments where network isolation isn't needed yet. Key decisions. Address space planning (don't overlap with on-premises or other VNets — use RFC 1918 ranges, plan for growth), subnet strategy (separate subnets per workload tier, delegate subnets for PaaS services), NSG (Network Security Group) rules per subnet, VNet peering vs VPN for cross-VNet connectivity.
When to use. Accessing PaaS services (Storage, SQL, Cosmos DB, Key Vault, Service Bus) over private IP addresses within your VNet. Eliminates public internet exposure for data-plane operations. Required for compliance in most enterprise environments. When to avoid. Development environments where the DNS complexity isn't justified. Services that don't support private endpoints. Key decisions. Private DNS zone integration (Azure-managed DNS zones for automatic resolution), DNS forwarding for hybrid networks, private endpoint per service per VNet, NSG support on private endpoints (recently added), approval workflow for cross-tenant connections.
When to use. Front Door for global HTTP load balancing, WAF, and CDN with anycast routing — multi-region applications. Application Gateway for regional L7 load balancing, WAF, and SSL termination within a single region. When to avoid. Front Door is overkill for single-region applications. Application Gateway is unnecessary if App Service or Container Apps built-in routing suffices. Key decisions. Front Door tier (Standard for CDN + routing, Premium for WAF + Private Link origins), WAF rule sets (Microsoft-managed + custom rules), caching rules, origin health probes, URL rewriting and routing rules.
When to use. Azure DNS for hosting DNS zones. Traffic Manager for DNS-based global traffic routing (geographic, weighted, priority, performance). Traffic Manager is L4 (DNS-level), not L7 — use Front Door for L7 global routing. When to avoid. Traffic Manager when you need L7 features (path-based routing, SSL termination, WAF). Front Door has superseded Traffic Manager for most HTTP workloads. Key decisions. DNS TTL values (low TTLs for failover speed, higher for caching), Traffic Manager routing method, health probe configuration, nested profiles for complex routing.
When to use. Relational workloads that need full SQL Server compatibility. Managed service with built-in HA, backups, patching. Serverless tier for intermittent workloads (auto-pause to save cost). Hyperscale for databases exceeding 4 TB. When to avoid. Non-relational workloads. When you need multi-model capabilities (consider Cosmos DB). When PostgreSQL-specific features are needed (use Azure Database for PostgreSQL Flexible Server). Key decisions. Purchasing model (DTU for simple, vCore for granular control), service tier (General Purpose vs Business Critical vs Hyperscale), elastic pools for multi-tenant SaaS (share resources across databases), geo-replication for DR, Managed Instance for SQL Server features not in SQL Database.
When to use. Globally distributed, multi-model database for low-latency reads and writes at any scale. Multi-region writes, tunable consistency (five levels from strong to eventual), sub-10ms reads. Document, key-value, graph, and column-family workloads. When to avoid. Simple relational workloads (SQL Database is cheaper and simpler). When strong consistency across all operations is non-negotiable (Cosmos DB's strong consistency has higher latency and RU cost). When the cost model doesn't fit (RU-based pricing is hard to predict for complex query patterns). Key decisions. API selection (NoSQL for documents, PostgreSQL for relational, MongoDB for compatibility, Cassandra for wide-column, Gremlin for graph, Table for key-value), consistency level (session consistency is the sweet spot for most apps), partition key design (this is THE critical decision — bad partition keys cause hot partitions and throttling), RU provisioning (autoscale vs manual), global distribution topology.
When to use. Blob Storage for unstructured data (images, videos, backups, data lake). Table Storage for simple key-value (cheaper than Cosmos DB for basic lookups). Queue Storage for simple message queuing. Files for SMB/NFS file shares. When to avoid. Table Storage when you need indexing, querying, or global distribution (use Cosmos DB). Queue Storage when you need advanced messaging features (use Service Bus). Blob Storage when you need a POSIX filesystem (use Azure NetApp Files or Azure Managed Lustre). Key decisions. Storage account redundancy (LRS for dev, ZRS for production, GRS/GZRS for DR), access tier (Hot/Cool/Cold/Archive — lifecycle management policies to auto-tier), private endpoints, immutability policies for compliance, blob versioning and soft delete.
When to use. PostgreSQL workloads on Azure. Full PostgreSQL compatibility with managed infrastructure. Better price-performance than Cosmos DB for relational patterns. Supports extensions (PostGIS, pgvector for AI workloads, Citus for distributed). When to avoid. When you need multi-region writes (Cosmos DB). When SQL Server compatibility is required (Azure SQL). When the workload is non-relational. Key decisions. Compute tier (Burstable for dev, General Purpose for most, Memory Optimized for analytics), high availability (zone-redundant with automatic failover), read replicas for read scaling, pgvector for AI/vector search, connection pooling (PgBouncer built-in).
When to use. Enterprise messaging with guaranteed delivery, ordering, transactions, and dead-lettering. Queues for point-to-point, topics for pub/sub. When message processing requires at-least-once or exactly-once semantics. When to avoid. High-throughput event streaming (use Event Hubs). Simple fire-and-forget notifications (use Event Grid). When the messaging features exceed what you need (Storage Queues are cheaper for simple queueing). Key decisions. Standard vs Premium tier (Premium for VNet integration, JMS support, and predictable performance), queue vs topic, session support for ordered processing per logical group, dead-letter queue monitoring and alerting, duplicate detection window.
When to use. High-throughput event streaming — telemetry ingestion, log aggregation, event sourcing, real-time analytics. Kafka-compatible API available. Millions of events per second. Capture to Storage or Data Lake for batch processing. When to avoid. Command-style messaging that needs guaranteed processing and dead-lettering (use Service Bus). Low-volume messaging where the throughput unit minimums make it expensive. Key decisions. Throughput units (Standard) vs Processing Units (Premium) vs Capacity Units (Dedicated), partition count (determines max consumer parallelism — can't be changed after creation), consumer group design, checkpoint storage (Blob Storage), retention period, Schema Registry for Avro/JSON schema governance.
When to use. Reactive event routing — responding to Azure resource events (blob created, resource provisioned) or custom events. Push-based delivery with filtering, retry, and dead-lettering. Event-driven architectures where producers don't know consumers. When to avoid. High-throughput streaming (use Event Hubs). Ordered processing or transactions (use Service Bus). When consumers need to pull at their own pace (Event Grid pushes to endpoints). Key decisions. System topics (Azure resource events) vs custom topics, event schema (Event Grid schema vs CloudEvents), subscription filtering (subject, event type, advanced filters), dead-letter destination, delivery retry policy, private endpoints for security.
When to use. All Azure infrastructure should be defined as code. Bicep is the Azure-native IaC language — compiles to ARM templates, simpler syntax, modules for reuse. First-party, always up-to-date with Azure API changes. When to avoid. Multi-cloud infrastructure (use Terraform for cloud-agnostic IaC). When the team already has deep Terraform expertise and the Azure provider coverage is sufficient. Key decisions. Bicep vs Terraform (Bicep for Azure-only, Terraform for multi-cloud or when the team knows it), module structure (per-resource-type modules, per-workload compositions), parameter files per environment, deployment scopes (resource group, subscription, management group), what-if validation before deployment.
When to use. CI/CD pipelines for building, testing, and deploying Azure workloads. Azure DevOps for enterprises already in the Microsoft ecosystem with Boards/Repos/Artifacts. GitHub Actions for teams on GitHub with simpler pipeline needs. When to avoid. Neither is wrong; choose based on where your code lives and what your team knows. Don't use both for the same project. Key decisions. Pipeline-as-code (YAML in both), environment approvals and gates, service connection security (federated credentials with Managed Identity, not stored secrets), artifact management, deployment strategy (rolling, blue-green, canary), variable groups and secret management.
Deployment slots (App Service, Functions). Zero-downtime deployments via slot swap. Deploy to staging slot, warm it up, swap to production. Swap is a DNS-level pointer change — instant. Auto-swap for CI/CD automation. Slot-specific settings for connection strings that differ per environment. Blue-green with Traffic Manager or Front Door. Route traffic between two identical environments. Deploy to the inactive environment, validate, shift traffic. More complex than slots but works for any compute type. Canary with Azure Front Door. Weighted routing to send a percentage of traffic to the new version. Monitor error rates and latency before increasing. Roll back by shifting weight to zero.
When to use. Always. Azure Monitor is the unified observability platform. Application Insights for application telemetry (traces, metrics, exceptions, dependencies), Log Analytics for centralized log querying (KQL), Monitor for alerts, dashboards, and autoscale rules. When to avoid. Never for Azure workloads. Complement with Grafana or third-party tools if needed, but Azure Monitor should be the foundation. Key decisions. Log Analytics workspace design (one per environment or one shared with RBAC), data retention (default 30 days, extend for compliance, archive for long-term), sampling rate for Application Insights (balance cost vs fidelity), alert rule design (metric alerts for speed, log alerts for complex conditions), action groups for notification routing.
When to use. Governance at scale — enforce tagging, restrict VM sizes, require encryption, deny public endpoints, audit compliance. Policies apply across subscriptions via management groups. Shift-left by evaluating in CI/CD pipelines. When to avoid. Application-level business rules (Policy is for infrastructure governance). Key decisions. Audit vs Deny effect (start with Audit to understand impact, graduate to Deny), initiative grouping (bundle related policies), exemptions for legitimate exceptions, custom policies for org-specific rules, remediation tasks for existing non-compliant resources.
When to use. Predictable workloads that will run for 1-3 years. Reserved Instances for specific VM sizes in specific regions (up to 72% savings). Savings Plans for flexible commitment across VM families, regions, and services (up to 65% savings). When to avoid. Variable or experimental workloads. Short-lived projects. When you can't predict the compute footprint for 1+ year. Key decisions. Reservation scope (shared vs single subscription), reservation vs savings plan (reservations save more but are less flexible), coverage analysis using Azure Advisor recommendations, exchange and cancellation policies.
When to use. Fault-tolerant, interruptible workloads — batch processing, CI/CD agents, dev/test environments, training jobs. Up to 90% discount. Azure can evict with 30 seconds notice. When to avoid. Production services that need availability. Stateful workloads that can't checkpoint and resume. When eviction would cause user-visible impact. Key decisions. Eviction policy (deallocate vs delete), max price setting, combining with on-demand VMs in Scale Sets for availability, checkpointing strategy for long-running jobs.
What it costs. Azure costs are notoriously easy to surprise on — idle resources, premium tiers left on after testing, storage growing silently, egress charges. Key strategies. Azure Cost Management budgets with alerts, daily cost anomaly review, resource tagging for cost attribution (enforce via Policy), Azure Advisor cost recommendations, regular rightsizing review, dev/test subscriptions with auto-shutdown, Cost Management exports for custom analysis.