@teckedd-code2save/b2dp 1.0.1 → 1.1.0

package/skills/cloud-solution-architect/references/design-principles.md

@@ -0,0 +1,328 @@
+# Azure Design Principles
+
+Ten principles for building reliable, scalable, and manageable applications on Azure.
+
+| # | Principle | Focus |
+|---|-----------|-------|
+| 1 | [Design for self-healing](#1-design-for-self-healing) | Resilience & automatic recovery |
+| 2 | [Make all things redundant](#2-make-all-things-redundant) | Eliminate single points of failure |
+| 3 | [Minimize coordination](#3-minimize-coordination) | Scalability through decoupling |
+| 4 | [Design to scale out](#4-design-to-scale-out) | Horizontal scaling |
+| 5 | [Partition around limits](#5-partition-around-limits) | Overcome service boundaries |
+| 6 | [Design for operations](#6-design-for-operations) | Observability & automation |
+| 7 | [Use managed services](#7-use-managed-services) | Reduce operational burden |
+| 8 | [Use an identity service](#8-use-an-identity-service) | Centralized identity & access |
+| 9 | [Design for evolution](#9-design-for-evolution) | Change-friendly architecture |
+| 10 | [Build for the needs of business](#10-build-for-the-needs-of-business) | Align tech to business goals |
+
+---
+
+## 1. Design for self-healing
+
+Design the application to detect failures, respond gracefully, and recover automatically without manual intervention.
+
+### Recommendations
+
+- **Implement retry logic with backoff** for transient failures in network calls, database connections, and external service interactions.
+- **Use health endpoint monitoring** to expose liveness and readiness probes so orchestrators and load balancers can route traffic away from unhealthy instances.
+- **Apply circuit breaker patterns** to prevent cascading failures — stop calling a failing dependency and allow it time to recover.
+- **Degrade gracefully** by serving reduced functionality (cached data, default responses) rather than failing entirely when a dependency is unavailable.
+- **Adopt chaos engineering** with Azure Chaos Studio to proactively inject faults and validate recovery paths before real incidents occur.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Retry | Handle transient faults by transparently retrying failed operations |
+| Circuit Breaker | Prevent repeated calls to a failing service |
+| Bulkhead | Isolate failures so one component doesn't take down others |
+| Health Endpoint Monitoring | Expose health checks for load balancers and orchestrators |
+| Leader Election | Coordinate distributed instances by electing a leader |
+| Throttling | Control resource consumption by limiting request rates |
+
+### Azure services
+
+- **Azure Chaos Studio** — fault injection and chaos experiments
+- **Azure Monitor / Application Insights** — health monitoring, alerting, diagnostics
+- **Azure Traffic Manager / Front Door** — DNS and global failover
+- **Availability Zones** — zonal redundancy within a region
+
+---
+
+## 2. Make all things redundant
+
+Build redundancy into the application at every layer to avoid single points of failure. Composite availability formula: `1 - (1 - A)^N` where A is the availability of a single instance and N is the number of instances.
+
+### Recommendations
+
+- **Place VMs behind a load balancer** and deploy multiple instances to ensure requests can be served even if one instance fails.
+- **Replicate databases** using read replicas, active geo-replication, or multi-region write to protect data and maintain read performance during outages.
+- **Use multi-zone and multi-region deployments** to survive datacenter and regional failures — define clear RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets.
+- **Partition workloads for availability** so that a failure in one partition doesn't affect others.
+- **Design for automatic failover** with health probes and traffic routing that redirects users without manual intervention.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Deployment Stamps | Deploy independent, identical copies of infrastructure |
+| Geode | Deploy backend services across geographies |
+| Health Endpoint Monitoring | Detect unhealthy instances for failover |
+| Queue-Based Load Leveling | Buffer requests to smooth demand spikes |
+
+### Azure services
+
+- **Azure Load Balancer / Application Gateway** — distribute traffic across instances
+- **Azure SQL geo-replication / Cosmos DB multi-region** — database redundancy
+- **Availability Zones** — zonal redundancy within a region
+- **Azure Site Recovery** — disaster recovery orchestration
+- **Azure Front Door** — global load balancing with automatic failover
+
+---
+
+## 3. Minimize coordination
+
+Minimize coordination between application services to achieve scalability. Tightly coupled services that require synchronous calls create bottlenecks and reduce availability.
+
+### Recommendations
+
+- **Embrace eventual consistency** instead of requiring strong consistency across services — accept that data may be temporarily out of sync.
+- **Use domain events and asynchronous messaging** to decouple producers and consumers so they can operate independently.
+- **Consider CQRS** (Command Query Responsibility Segregation) to separate read and write workloads with independently optimized stores.
+- **Design idempotent operations** so messages can be safely retried or delivered more than once without unintended side effects.
+- **Use optimistic concurrency** with version tokens or ETags instead of pessimistic locks that create coordination bottlenecks.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| CQRS | Separate reads from writes for independent scaling |
+| Event Sourcing | Capture all changes as an immutable sequence of events |
+| Saga | Manage distributed transactions without two-phase commit |
+| Asynchronous Request-Reply | Decouple request and response across services |
+| Competing Consumers | Process messages in parallel across multiple consumers |
+
+### Azure services
+
+- **Azure Service Bus** — reliable enterprise messaging with queues and topics
+- **Azure Event Grid** — event-driven routing at scale
+- **Azure Event Hubs** — high-throughput event streaming
+- **Azure Cosmos DB** — tunable consistency levels (eventual to strong)
+
+---
+
+## 4. Design to scale out
+
+Design the application so it can scale horizontally by adding or removing instances, rather than scaling up to larger hardware.
+
+### Recommendations
+
+- **Avoid instance stickiness and session affinity** — store session state externally (Redis, database) so any instance can handle any request.
+- **Identify and resolve bottlenecks** that prevent horizontal scaling, such as shared databases, monolithic components, or stateful in-memory caches.
+- **Decompose workloads** into discrete services that can be scaled independently based on their specific demand profiles.
+- **Use autoscaling based on live metrics** (CPU, queue depth, request latency) rather than fixed schedules to match capacity to real demand.
+- **Design for scale-in** — handle instance removal gracefully with connection draining and proper shutdown hooks.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Competing Consumers | Distribute work across multiple consumers |
+| Sharding | Distribute data across partitions for parallel processing |
+| Deployment Stamps | Scale by deploying additional independent stamps |
+| Static Content Hosting | Offload static assets to reduce compute load |
+| Throttling | Protect the system from overload during scale events |
+
+### Azure services
+
+- **Azure Virtual Machine Scale Sets** — autoscale VM pools
+- **Azure App Service / Azure Functions** — built-in autoscale
+- **Azure Kubernetes Service (AKS)** — horizontal pod autoscaler and cluster autoscaler
+- **Azure Cache for Redis** — externalize session state
+- **Azure CDN / Front Door** — offload static content delivery
+
+---
+
+## 5. Partition around limits
+
+Use partitioning to work around database, network, and compute limits. Every Azure service has limits — partitioning allows you to scale beyond them.
+
+### Recommendations
+
+- **Partition databases** horizontally (sharding), vertically (splitting columns), or functionally (by bounded context) to distribute load and storage.
+- **Design partition keys to avoid hotspots** — choose keys that distribute data and traffic evenly across partitions.
+- **Partition at different levels** — database, queue, network, and compute — to address bottlenecks wherever they occur.
+- **Understand service-specific limits** for throughput, connections, storage, and request rates and design partitioning strategies accordingly.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Sharding | Distribute data across multiple databases or partitions |
+| Priority Queue | Process high-priority work before lower-priority work |
+| Queue-Based Load Leveling | Buffer writes to smooth spikes |
+| Valet Key | Grant limited direct access to resources |
+
+### Azure services
+
+- **Azure Cosmos DB** — automatic partitioning with configurable partition keys
+- **Azure SQL Elastic Pools** — manage and scale multiple databases
+- **Azure Storage** — table, blob, and queue partitioning
+- **Azure Service Bus** — partitioned queues and topics
+
+---
+
+## 6. Design for operations
+
+Design the application so that the operations team has the tools they need to monitor, diagnose, and manage it in production.
+
+### Recommendations
+
+- **Instrument everything** with structured logging, distributed tracing, and metrics to make the system observable from day one.
+- **Use distributed tracing** with correlation IDs that flow across service boundaries to diagnose issues in microservices architectures.
+- **Automate operational tasks** — deployments, scaling, failover, and routine maintenance should require no manual steps.
+- **Treat configuration as code** — store all environment configuration in version control and deploy it through the same CI/CD pipelines as application code.
+- **Implement dashboards and alerts** that surface actionable information, not just raw data, so operators can respond quickly.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Health Endpoint Monitoring | Expose operational health for monitoring tools |
+| Ambassador | Offload cross-cutting concerns like logging and monitoring |
+| Sidecar | Deploy monitoring agents alongside application containers |
+| External Configuration Store | Centralize configuration management |
+
+### Azure services
+
+- **Azure Monitor** — metrics, logs, and alerts across all Azure resources
+- **Application Insights** — application performance monitoring and distributed tracing
+- **Azure Log Analytics** — centralized log querying with KQL
+- **Azure Resource Manager (ARM) / Bicep** — infrastructure as code
+- **Azure DevOps / GitHub Actions** — CI/CD pipelines
+
+---
+
+## 7. Use managed services
+
+Prefer platform as a service (PaaS) over infrastructure as a service (IaaS) wherever possible to reduce operational overhead.
+
+### Recommendations
+
+- **Default to PaaS** for compute, databases, messaging, and storage — let Azure handle OS patching, scaling, and high availability.
+- **Use IaaS only when you need fine-grained control** over the operating system, runtime, or network configuration that PaaS cannot provide.
+- **Leverage built-in scaling and redundancy** features of managed services instead of building and maintaining them yourself.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Backends for Frontends | Use managed API gateways per client type |
+| Gateway Aggregation | Aggregate calls through a managed gateway |
+| Static Content Hosting | Use managed storage for static assets |
+
+### Azure services
+
+| IaaS | PaaS Alternative |
+|------|-------------------|
+| VMs with IIS/Nginx | Azure App Service |
+| VMs with SQL Server | Azure SQL Database |
+| VMs with RabbitMQ | Azure Service Bus |
+| VMs with Kubernetes | Azure Kubernetes Service (AKS) |
+| VMs with custom functions | Azure Functions |
+| VMs with Redis | Azure Cache for Redis |
+| VMs with Elasticsearch | Azure AI Search |
+
+---
+
+## 8. Use an identity service
+
+Use a centralized identity platform instead of building or managing your own authentication and authorization system.
+
+### Recommendations
+
+- **Use Microsoft Entra ID** (formerly Azure AD) as the single identity provider for users, applications, and service-to-service authentication.
+- **Never store credentials in application code or configuration** — use managed identities, certificate-based auth, or federated credentials.
+- **Implement federation protocols** (SAML, OIDC, OAuth 2.0) to integrate with external identity providers and enable single sign-on.
+- **Adopt modern security features** — passwordless authentication (FIDO2, Windows Hello), conditional access policies, multi-factor authentication (MFA), and single sign-on (SSO).
+- **Use managed identities for Azure resources** to eliminate credential management for service-to-service communication entirely.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Federated Identity | Delegate authentication to an external identity provider |
+| Gatekeeper | Protect backends by validating identity at the edge |
+| Valet Key | Grant scoped, time-limited access to resources |
+
+### Azure services
+
+- **Microsoft Entra ID** — cloud identity and access management
+- **Azure Managed Identities** — credential-free service-to-service auth
+- **Azure Key Vault** — secrets, certificates, and key management
+- **Microsoft Entra External ID** — customer and partner identity (B2C/B2B)
+
+---
+
+## 9. Design for evolution
+
+Design the architecture so it can evolve over time as requirements, technologies, and team understanding change.
+
+### Recommendations
+
+- **Enforce loose coupling and high cohesion** — services should expose well-defined interfaces and encapsulate their internal implementation details.
+- **Encapsulate domain knowledge** within service boundaries so changes to business logic don't ripple across the system.
+- **Use asynchronous messaging** between services to reduce temporal coupling — services don't need to be available at the same time.
+- **Version APIs** from day one so clients can migrate at their own pace and you can evolve without breaking existing consumers.
+- **Deploy services independently** with their own release cadence — avoid coordinated "big bang" deployments.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Anti-Corruption Layer | Isolate new services from legacy systems |
+| Strangler Fig | Incrementally migrate a monolith to microservices |
+| Backends for Frontends | Evolve APIs independently per client type |
+| Gateway Routing | Route requests to different service versions |
+
+### Azure services
+
+- **Azure API Management** — API versioning, routing, and lifecycle management
+- **Azure Kubernetes Service (AKS)** — independent service deployments with rolling updates
+- **Azure Service Bus** — asynchronous inter-service messaging
+- **Azure Container Apps** — revision-based deployments with traffic splitting
+
+---
+
+## 10. Build for the needs of business
+
+Every design decision must be justified by a business requirement. Align technical choices with business goals, constraints, and growth plans.
+
+### Recommendations
+
+- **Define RTO, RPO, and MTO** (Recovery Time Objective, Recovery Point Objective, Maximum Tolerable Outage) for each workload based on business impact analysis.
+- **Document SLAs and SLOs** — understand the composite SLA of your architecture and set internal SLOs that provide an error budget for engineering work.
+- **Model the system around the business domain** using domain-driven design to ensure the architecture reflects how the business operates.
+- **Define functional and nonfunctional requirements explicitly** — capture performance targets, compliance needs, data residency constraints, and user experience expectations.
+- **Plan for growth** — design capacity models that account for business projections, seasonal peaks, and market expansion.
+
+### Related design patterns
+
+| Pattern | Purpose |
+|---------|---------|
+| Priority Queue | Process business-critical work first |
+| Throttling | Protect SLOs under heavy load |
+| Deployment Stamps | Scale to new markets and regions |
+| Bulkhead | Isolate critical workloads from non-critical ones |
+
+### Azure services
+
+- **Azure Advisor** — cost, performance, reliability, and security recommendations
+- **Azure Cost Management** — budget tracking and cost optimization
+- **Azure Service Health** — SLA tracking and incident awareness
+- **Azure Well-Architected Framework Review** — assess architecture against best practices
+- **Azure Monitor SLO/SLI dashboards** — measure and track service level objectives
+
+---
+
+> Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/)

package/skills/cloud-solution-architect/references/mission-critical.md

@@ -0,0 +1,285 @@
+# Mission-Critical Architecture on Azure
+
+Guidance for designing mission-critical workloads on Azure that prioritize cloud-native capabilities to maximize reliability and operational effectiveness.
+
+**Target SLO:** **99.99%** or higher — permitted annual downtime: **52 minutes 35 seconds**.
+
+All encompassed design decisions are intended to accomplish this target SLO.
+
+| SLO Target | Permitted Annual Downtime | Typical Use Case |
+|---|---|---|
+| 99.9% | 8 hours 45 minutes | Standard business apps |
+| 99.95% | 4 hours 22 minutes | Important business apps |
+| 99.99% | 52 minutes 35 seconds | Mission-critical workloads |
+| 99.999% | 5 minutes 15 seconds | Safety-critical systems |
+
+---
+
+## Key Design Strategies
+
+### 1. Redundancy in Layers
+
+Deploy redundancy at every layer of the architecture to eliminate single points of failure.
+
+- Deploy to multiple regions in an **active-active** model — application distributed across 2+ Azure regions handling active user traffic simultaneously
+- Utilize **availability zones** for all considered services — distributing components across physically separate datacenters inside a region
+- Choose resources that support **global distribution** natively
+- Apply zone-redundant configurations for all stateful services
+- Ensure data replication meets RPO requirements across regions
+
+**Azure services:** Azure Front Door (global routing), Azure Traffic Manager (DNS failover), Azure Cosmos DB (multi-region writes), Azure SQL (geo-replication)
+
+### 2. Deployment Stamps
+
+Deploy regional stamps as scale units — a logical set of resources that can be independently provisioned to keep up with demand changes.
+
+- Each stamp is a **self-contained scale unit** with its own compute, caching, and local state
+- Multiple nested scale units within a stamp (e.g., Frontend APIs and Background processors scale independently)
+- **No dependencies between scale units** — they only communicate with shared services outside the stamp
+- Scale units are **temporary/ephemeral** — store persistent system-of-record data only in the replicated database
+- Use stamps for blue-green deployments by rolling out new units, validating, and gradually shifting traffic
+
+**Key benefit:** Compartmentalization enables independent scaling and fault isolation per region.
+
+### 3. Reliable and Repeatable Deployments
+
+Apply the principle of Infrastructure as Code (IaC) for version control and standardized operations.
+
+- Use **Terraform** or **Bicep** for infrastructure definition with version control
+- Implement **zero-downtime blue/green deployment** pipelines — build and release pipelines fully automated
+- Apply **environment consistency** — use the same deployment pipeline code across production and pre-production environments
+- Integrate **continuous validation** — automated testing as part of DevOps processes
+- Include synchronized **load and chaos testing** to validate both application code and underlying infrastructure
+- Deploy stamps as a **single operational unit** — never partially deploy a stamp
+
+### 4. Operational Insights
+
+Build comprehensive observability without introducing single points of failure.
+
+- Use **federated workspaces** for observability data — monitoring data for global and regional resources stored independently
+- A centralized observability store is **NOT recommended** (it becomes a single point of failure)
+- Use **cross-workspace querying** to achieve a unified data sink and single pane of glass for operations
+- Construct a **layered health model** mapping application health to a traffic light model for contextualizing
+- Health scores calculated for each **individual component**, then **aggregated at user flow level**
+- Combine with key non-functional requirements (performance) as coefficients to quantify application health
+
+---
+
+## Design Areas
+
+Each design area must be addressed for a mission-critical architecture.
+
+| Design Area | Description | Key Concerns |
+|---|---|---|
+| **Application platform** | Infrastructure choices and mitigations for potential failure cases | AKS vs App Service, availability zones, containerization |
+| **Application design** | Design patterns that allow for scaling and error handling | Stateless services, async messaging, queue-based decoupling |
+| **Networking and connectivity** | Network considerations for routing incoming traffic to stamps | Global load balancing, WAF, DDoS protection, private endpoints |
+| **Data platform** | Choices in data store technologies | Volume, velocity, variety, veracity; active-active vs active-passive |
+| **Deployment and testing** | Strategies for CI/CD pipelines and automation | Blue/green deployments, load testing, chaos testing |
+| **Health modeling** | Observability through customer impact analysis | Correlated monitoring, traffic light model, health scores |
+| **Security** | Mitigation of attack vectors | Microsoft Zero Trust model, identity-based access, encryption |
+| **Operational procedures** | Processes related to runtime operations | Deployment SOPs, key management, patching, incident response |
+
+---
+
+## Active-Active Multi-Region Architecture
+
+The core topology for mission-critical workloads distributes the application across multiple Azure regions.
+
+### Architecture Characteristics
+
+- Application distributed across **2+ Azure regions** handling active user traffic simultaneously
+- Each region contains independent **deployment stamps** (scale units)
+- **Azure Front Door** provides global routing, SSL termination, and WAF at the edge
+- Scale units have **no cross-dependencies** — they communicate only with shared services (e.g., global database, DNS)
+- Persistent data resides only in the **replicated database** — stamps store no durable local state
+- When scale units are replaced or retired, applications reconnect transparently
+
+### Data Replication Strategies
+
+| Strategy | Writes | Reads | Consistency | Best For |
+|---|---|---|---|---|
+| Active-passive (Azure SQL) | Single primary region | All regions via read replicas | Strong | Relational data, ACID transactions |
+| Active-active (Cosmos DB) | All regions | All regions | Tunable (5 levels) | Document/key-value data, global apps |
+| Write-behind (Redis → SQL) | Redis first, async to SQL | Redis or SQL | Eventual | High-throughput writes, rate limiting |
+
+### Regional Stamp Composition
+
+Each stamp typically includes:
+
+- **Compute tier** — App Service or AKS with multiple instances across availability zones
+- **Caching tier** — Azure Managed Redis for session state, rate limiting, feature flags
+- **Configuration** — Azure App Configuration for settings (capacity correlates with requests/second)
+- **Secrets** — Azure Key Vault for certificates and secrets
+- **Networking** — Virtual network with private endpoints, NSGs, and service endpoints
+
+---
+
+## Health Modeling and Traffic Light Approach
+
+Health modeling provides the foundation for automated operational decisions.
+
+### Building the Health Model
+
+1. **Identify user flows** — map critical paths through the application (e.g., "user login", "checkout", "search")
+2. **Decompose into components** — each flow depends on specific compute, data, and network components
+3. **Assign health scores** — each component reports a health score based on metrics (latency, error rate, saturation)
+4. **Aggregate per flow** — combine component scores weighted by criticality to produce a flow-level health score
+5. **Apply traffic light** — map aggregate scores to **Green** (healthy), **Yellow** (degraded), **Red** (unhealthy)
+
+### Health Score Coefficients
+
+| Factor | Metric Examples | Weight Guidance |
+|---|---|---|
+| Availability | Error rate, HTTP 5xx ratio | High — directly impacts users |
+| Performance | P95 latency, request duration | Medium — affects user experience |
+| Saturation | CPU %, memory %, queue depth | Medium — indicates future problems |
+| Freshness | Data replication lag, cache age | Lower — depends on consistency needs |
+
+### Operational Actions by Health State
+
+| State | Meaning | Automated Action |
+|---|---|---|
+| 🟢 Green | All components healthy | Normal operations |
+| 🟡 Yellow | Degraded but functional | Alert on-call, increase monitoring frequency |
+| 🔴 Red | Critical failure detected | Trigger failover, page on-call, block deployments |
+
+---
+
+## Zero-Downtime Deployment (Blue/Green)
+
+Deployment must never cause downtime in a mission-critical system.
+
+### Blue/Green Process
+
+1. **Provision new stamp** — deploy a complete new scale unit ("green") alongside the existing one ("blue")
+2. **Run validation** — execute automated smoke tests, integration tests, and synthetic transactions against the green stamp
+3. **Canary traffic** — route a small percentage of production traffic (e.g., 5%) to the green stamp
+4. **Monitor health** — compare health scores between blue and green stamps over a defined observation period
+5. **Gradual shift** — increase traffic to green stamp in increments (5% → 25% → 50% → 100%)
+6. **Decommission blue** — once green is fully validated, tear down the blue stamp
+
+### Key Requirements
+
+- Build and release pipelines must be **fully automated** — no manual deployment steps
+- Use the **same pipeline code** for all environments (dev, staging, production)
+- Each stamp deployed as a **single operational unit** — never partial
+- Rollback is achieved by **shifting traffic back** to the previous stamp (still running during validation)
+- **Continuous validation** runs throughout the deployment, not just at the end
+
+---
+
+## Chaos Engineering and Continuous Validation
+
+Proactive failure testing ensures recovery mechanisms work before real incidents occur.
+
+### Chaos Engineering Practices
+
+- Use **Azure Chaos Studio** to run controlled experiments against production or pre-production environments
+- Test failure modes: availability zone outage, network partition, dependency failure, CPU/memory pressure
+- Run chaos experiments as part of the **CI/CD pipeline** — every deployment is validated under fault conditions
+- **Synchronized load and chaos testing** — inject faults while the system is under realistic load
+
+### Validation Checklist
+
+- [ ] Health model detects injected faults within SLO-defined time windows
+- [ ] Automated failover completes within target RTO
+- [ ] No data loss exceeding target RPO during regional failover
+- [ ] Application degrades gracefully (reduced functionality, not total failure)
+- [ ] Alerts fire correctly and reach the on-call team
+- [ ] Runbooks and automated remediation execute successfully
+
+---
+
+## Application Platform Considerations
+
+### Platform Options
+
+| Platform | Best For | Availability Zone Support | Complexity |
+|---|---|---|---|
+| **Azure App Service** | Web apps, APIs, PaaS-first approach | Yes (zone-redundant) | Low-Medium |
+| **AKS** | Complex microservices, full K8s control | Yes (zone-redundant node pools) | High |
+| **Container Apps** | Serverless containers, event-driven | Yes | Medium |
+
+### Recommendations
+
+- **Prioritize availability zones** for all production workloads — spread across physically separate datacenters
+- **Containerize workloads** for reliability and portability between platforms
+- Ensure all services in a scale unit support availability zones — don't mix zonal and non-zonal services
+- For latency-sensitive or chatty workloads, consider tradeoffs of cross-zone traffic cost and latency
+
+---
+
+## Data Platform Considerations
+
+### Choosing a Primary Database
+
+| Scenario | Recommended Service | Deployment Model |
+|---|---|---|
+| Relational data, ACID transactions | **Azure SQL** | Active-passive with geo-replication |
+| Global distribution, multi-model | **Azure Cosmos DB** | Active-active with multi-region writes |
+| Multiple microservice databases | **Mixed (polyglot)** | Per-service database with appropriate model |
+
+### Azure SQL in Mission-Critical
+
+- Azure SQL does **not** natively support active-active concurrent writes in multiple regions
+- Use **active-passive** strategy: single primary region for writes, read replicas in secondary regions
+- **Partial active-active** possible at the application tier — route reads to local replicas, writes to primary
+- Configure **auto-failover groups** for automated regional failover
+
+### Azure Managed Redis in Mission-Critical
+
+- Use within or alongside each scale unit for:
+  - **Cache data** — rebuildable, repopulated on demand
+  - **Session state** — user sessions during scale unit lifetime
+  - **Rate limit counters** — per-user and per-tenant throttling
+  - **Feature flags** — dynamic configuration without redeployment
+  - **Coordination metadata** — distributed locks, leader election
+- **Active geo-replication** enables Redis data to replicate asynchronously across regions
+- Design cached data as either **rebuildable** (repopulate without availability impact) or **durable auxiliary state** (protected by persistence and geo-replication)
+
+---
+
+## Security in Mission-Critical
+
+### Zero Trust Principles
+
+- **Verify explicitly** — authenticate and authorize based on all available data points (identity, location, device, service)
+- **Use least privilege access** — limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA)
+- **Assume breach** — minimize blast radius and segment access, verify end-to-end encryption, use analytics for threat detection
+
+### Security Controls
+
+| Layer | Control | Azure Service |
+|---|---|---|
+| Edge | DDoS protection, WAF | Azure Front Door, Azure DDoS Protection |
+| Identity | Managed identities, RBAC | Microsoft Entra ID, Azure RBAC |
+| Network | Private endpoints, NSGs | Azure Private Link, Virtual Network |
+| Data | Encryption at rest and in transit | Azure Key Vault, TDE, TLS 1.2+ |
+| Operations | Privileged access management | Microsoft Entra PIM, Azure Bastion |
+
+---
+
+## Operational Procedures
+
+### Key Operational Processes
+
+| Process | Description | Automation Level |
+|---|---|---|
+| **Deployment** | Blue/green with automated validation | Fully automated |
+| **Scaling** | Stamp provisioning and decommissioning | Automated with manual approval gates |
+| **Key rotation** | Certificate and secret rotation | Automated via Key Vault policies |
+| **Patching** | OS and runtime updates | Automated via platform (PaaS) or pipeline (IaaS) |
+| **Incident response** | Detection, triage, mitigation, resolution | Semi-automated (alert → runbook → human) |
+| **Capacity planning** | Forecast demand, pre-provision stamps | Manual with data-driven analysis |
+
+### Runbook Requirements
+
+- All operational runbooks must be **tested in pre-production** with the same chaos/load scenarios as production
+- **Automated remediation** preferred over manual intervention for known failure modes
+- Runbooks must include **rollback procedures** for every change type
+- **Post-incident reviews** (blameless) must feed back into health model and chaos experiment improvements
+
+---
+
+> Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/)