@teckedd-code2save/b2dp 1.0.1 → 1.1.0

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

@@ -0,0 +1,873 @@
+# Cloud Design Patterns
+
+A comprehensive reference of all 44 cloud design patterns from the Azure Architecture Center, organized by concern area and detailed with problem context, usage scenarios, WAF pillar alignment, and related patterns.
+
+---
+
+## Patterns by Concern
+
+### Availability / Reliability
+
+Circuit Breaker · Compensating Transaction · Health Endpoint Monitoring · Leader Election · Queue-Based Load Leveling · Retry · Saga · Scheduler Agent Supervisor · Sequential Convoy · Bulkhead · Rate Limiting
+
+### Data Management
+
+Cache-Aside · CQRS · Event Sourcing · Index Table · Materialized View · Sharding · Valet Key · Claim Check
+
+### Design / Implementation
+
+Ambassador · Anti-Corruption Layer · Backends for Frontends · Compute Resource Consolidation · Deployment Stamps · External Configuration Store · Gateway Aggregation · Gateway Offloading · Gateway Routing · Sidecar · Strangler Fig · Federated Identity
+
+### Messaging
+
+Asynchronous Request-Reply · Choreography · Claim Check · Competing Consumers · Messaging Bridge · Pipes and Filters · Priority Queue · Publisher/Subscriber · Queue-Based Load Leveling · Sequential Convoy
+
+### Performance / Scalability
+
+Cache-Aside · Geode · Throttling · Deployment Stamps · CQRS
+
+### Security
+
+Gatekeeper · Quarantine · Valet Key · Federated Identity · Throttling
+
+---
+
+## Pattern Reference
+
+### 1. Ambassador
+
+**Create helper services that send network requests on behalf of a consumer service or application.**
+
+**Problem:** Applications need common connectivity features such as monitoring, logging, routing, security (TLS), and resiliency patterns. Legacy or difficult-to-modify apps may not support these features natively. Network calls require substantial configuration for concerns such as circuit breaking, routing, metering, and telemetry.
+
+**When to use:**
+
+- You need a common set of client connectivity features across multiple languages or frameworks
+- The connectivity concern is owned by infrastructure teams or another specialized team
+- You need to reduce the age or complexity of legacy app networking without modifying source code
+- You want to standardize observability and resiliency across polyglot services
+
+**WAF Pillars:** Reliability, Security
+
+**Related patterns:** Sidecar, Gateway Routing, Gateway Offloading
+
+---
+
+### 2. Anti-Corruption Layer
+
+**Implement a façade or adapter layer between a modern application and a legacy system.**
+
+**Problem:** During migration, the new system must often integrate with the legacy system's data model or API, which may use outdated schemas, protocols, or design conventions. Allowing the modern application to depend on legacy contracts contaminates its design and limits future evolution.
+
+**When to use:**
+
+- A migration is planned over multiple phases and the old and new systems must coexist
+- The new system's domain model differs significantly from the legacy system
+- You want to prevent legacy coupling from leaking into modern components
+- Two bounded contexts (DDD) need to communicate but have incompatible models
+
+**WAF Pillars:** Operational Excellence
+
+**Related patterns:** Strangler Fig, Gateway Routing
+
+---
+
+### 3. Asynchronous Request-Reply
+
+**Decouple backend processing from a frontend host, where backend processing needs to be asynchronous but the frontend still needs a clear response.**
+
+**Problem:** In many architectures, the client expects an immediate acknowledgement while the actual work happens in the background. The client needs a way to learn the result of the background operation without holding a long-lived connection or repeatedly guessing when processing completes.
+
+**When to use:**
+
+- Backend processing may take seconds to minutes and the client should not block
+- Client-side code such as a browser app cannot provide a callback endpoint
+- You want to expose an HTTP API where the server initiates long-running work and the client polls for results
+- You need an alternative to WebSocket or server-sent events for status updates
+
+**WAF Pillars:** Performance Efficiency
+
+**Related patterns:** Competing Consumers, Pipes and Filters, Queue-Based Load Leveling
+
+---
+
+### 4. Backends for Frontends
+
+**Create separate backend services to be consumed by specific frontend applications or interfaces.**
+
+**Problem:** A general-purpose backend API tends to accumulate conflicting requirements from different frontends (mobile, web, desktop, IoT). Over time the backend becomes bloated and changes for one frontend risk breaking another. Release cadences diverge and the single backend becomes a bottleneck.
+
+**When to use:**
+
+- A shared backend must be maintained with significant development overhead for multiple frontends
+- You want to optimize each backend for the constraints of a specific client (bandwidth, latency, payload shape)
+- Different frontend teams need independent release cycles for their backend logic
+- A single backend would require complex, client-specific branching logic
+
+**WAF Pillars:** Reliability, Security, Performance Efficiency
+
+**Related patterns:** Gateway Aggregation, Gateway Offloading, Gateway Routing
+
+---
+
+### 5. Bulkhead
+
+**Isolate elements of an application into pools so that if one fails, the others continue to function.**
+
+**Problem:** A cloud-based application may call multiple downstream services. If a single downstream becomes slow or unresponsive, the caller's thread pool or connection pool can be exhausted, causing cascading failure that takes down unrelated functionality.
+
+**When to use:**
+
+- You need to protect critical consumers from failures in non-critical downstream dependencies
+- A single noisy tenant or request type should not degrade service for others
+- You want to limit the blast radius of a downstream fault
+- The application calls multiple services with differing SLAs
+
+**WAF Pillars:** Reliability, Security, Performance Efficiency
+
+**Related patterns:** Circuit Breaker, Retry, Throttling, Queue-Based Load Leveling
+
+---
+
+### 6. Cache-Aside
+
+**Load data on demand into a cache from a data store.**
+
+**Problem:** Applications frequently read the same data from a data store. Repeated round trips increase latency and reduce throughput. Data stores may throttle or become expensive under high read loads.
+
+**When to use:**
+
+- The data store is read-heavy and the same data is requested frequently
+- The data store does not natively provide caching
+- Data can tolerate short periods of staleness
+- You want to reduce cost and latency of repeated reads
+
+**WAF Pillars:** Reliability, Performance Efficiency
+
+**Related patterns:** Materialized View, Event Sourcing, CQRS
+
+---
+
+### 7. Choreography
+
+**Have each component of the system participate in the decision-making process about the workflow of a business transaction, instead of relying on a central point of control.**
+
+**Problem:** A central orchestrator can become a single point of failure, a performance bottleneck, or a source of tight coupling. Changes to the workflow require changes to the orchestrator, which may be owned by a different team.
+
+**When to use:**
+
+- Services are independently deployable and owned by separate teams
+- The workflow changes frequently and a central orchestrator would become a maintenance burden
+- You want to avoid a single point of failure in workflow coordination
+- Services need loose coupling and can react to events
+
+**WAF Pillars:** Operational Excellence, Performance Efficiency
+
+**Related patterns:** Publisher/Subscriber, Saga, Competing Consumers
+
+---
+
+### 8. Circuit Breaker
+
+**Handle faults that might take a variable amount of time to fix when connecting to a remote service or resource.**
+
+**Problem:** Transient faults are handled by the Retry pattern, but when a downstream service is unavailable for an extended period, retries waste resources and block callers. Continuing to send requests to a failing service prevents it from recovering and wastes the caller's threads, connections, and compute.
+
+**When to use:**
+
+- A remote dependency experiences intermittent prolonged outages
+- You need to fail fast rather than make callers wait for a timeout
+- You want to give a failing downstream time to recover before sending more requests
+- You want to surface degraded functionality instead of hard failures
+
+**WAF Pillars:** Reliability, Performance Efficiency
+
+**Related patterns:** Retry, Bulkhead, Health Endpoint Monitoring, Ambassador
+
+---
+
+### 9. Claim Check
+
+**Split a large message into a claim check and payload to avoid overwhelming the messaging infrastructure.**
+
+**Problem:** Message brokers and queues often have size limits and charge per message. Sending large payloads (images, documents, datasets) through the messaging channel wastes bandwidth, increases cost, and may hit transport limits.
+
+**When to use:**
+
+- The message payload exceeds the messaging system's size limit
+- You want to reduce messaging costs by keeping message bodies small
+- Not all consumers need the full payload; some only need metadata
+- You need to protect sensitive payload data by separating access control from the messaging channel
+
+**WAF Pillars:** Reliability, Security, Cost Optimization, Performance Efficiency
+
+**Related patterns:** Competing Consumers, Pipes and Filters, Publisher/Subscriber
+
+---
+
+### 10. Compensating Transaction
+
+**Undo the work performed by a series of steps, which together define an eventually consistent operation.**
+
+**Problem:** In distributed systems, multi-step operations cannot rely on traditional ACID transactions. If a later step fails, the previous steps have already committed. The system needs a mechanism to reverse or compensate for the work done by the completed steps.
+
+**When to use:**
+
+- Multi-step operations span multiple services or data stores that do not share a transaction coordinator
+- You need to maintain consistency when a step in a distributed workflow fails
+- Rolling back is semantically meaningful (refund a charge, release a reservation)
+- The cost of inconsistency outweighs the complexity of compensation logic
+
+**WAF Pillars:** Reliability
+
+**Related patterns:** Saga, Retry, Scheduler Agent Supervisor
+
+---
+
+### 11. Competing Consumers
+
+**Enable multiple concurrent consumers to process messages received on the same messaging channel.**
+
+**Problem:** At peak load, a single consumer cannot keep up with the volume of incoming messages. Messages queue up, latency increases, and the system may breach its SLAs.
+
+**When to use:**
+
+- The workload varies significantly and you need to scale message processing dynamically
+- You require high availability—if one consumer fails, others continue processing
+- Multiple messages are independent and can be processed in parallel
+- You want to distribute work across multiple instances or nodes
+
+**WAF Pillars:** Reliability, Cost Optimization, Performance Efficiency
+
+**Related patterns:** Queue-Based Load Leveling, Priority Queue, Publisher/Subscriber, Pipes and Filters
+
+---
+
+### 12. Compute Resource Consolidation
+
+**Consolidate multiple tasks or operations into a single computational unit.**
+
+**Problem:** Deploying each small task or component as a separate service introduces operational overhead: more deployments, monitoring endpoints, and infrastructure cost. Many lightweight components are underutilized most of the time, wasting allocated compute.
+
+**When to use:**
+
+- Several lightweight processes have low CPU or memory usage individually
+- You want to reduce deployment and operational overhead
+- Processes share the same scaling profile and lifecycle
+- Communication between tasks benefits from being in-process rather than over the network
+
+**WAF Pillars:** Cost Optimization, Operational Excellence, Performance Efficiency
+
+**Related patterns:** Sidecar, Backends for Frontends
+
+---
+
+### 13. CQRS (Command and Query Responsibility Segregation)
+
+**Segregate operations that read data from operations that update data by using separate interfaces.**
+
+**Problem:** In traditional CRUD architectures, the same data model is used for reads and writes. This creates tension: read models want denormalized, query-optimized shapes while write models want normalized, consistency-optimized shapes. As the system grows, the shared model becomes a compromise that serves neither concern well.
+
+**When to use:**
+
+- Read and write workloads are asymmetric (far more reads than writes, or vice versa)
+- Read and write models have different schema requirements
+- You want to scale read and write sides independently
+- The domain benefits from an event-driven or task-based style rather than CRUD
+
+**WAF Pillars:** Performance Efficiency
+
+**Related patterns:** Event Sourcing, Materialized View, Cache-Aside
+
+---
+
+### 14. Deployment Stamps
+
+**Deploy multiple independent copies of application components, including data stores.**
+
+**Problem:** A single shared deployment for all tenants or regions creates coupling. A fault in one tenant's workload can affect all tenants. Regulatory requirements may mandate data residency. Scaling the entire deployment for a single tenant's spike is wasteful.
+
+**When to use:**
+
+- You need to isolate tenants for compliance, performance, or fault isolation
+- Your application must serve multiple geographic regions with data residency requirements
+- You need independent scaling per tenant group or region
+- You want blue/green or canary deployments at the stamp level
+
+**WAF Pillars:** Operational Excellence, Performance Efficiency
+
+**Related patterns:** Geode, Sharding, Throttling
+
+---
+
+### 15. Edge Workload Configuration
+
+**Centrally configure workloads that run at the edge, managing configuration drift and deployment consistency across heterogeneous edge devices.**
+
+**Problem:** Edge devices are numerous, heterogeneous, and often intermittently connected. Deploying and configuring workloads individually is error-prone. Configuration drift between devices causes inconsistent behavior and difficult debugging.
+
+**When to use:**
+
+- You manage a fleet of edge devices running the same workload with differing local parameters
+- Edge devices have intermittent connectivity and must operate independently
+- You need a central source of truth for configuration with local overrides
+- Audit and compliance require tracking which configuration each device is running
+
+**WAF Pillars:** Operational Excellence
+
+**Related patterns:** External Configuration Store, Sidecar, Ambassador
+
+---
+
+### 16. Event Sourcing
+
+**Use an append-only store to record the full series of events that describe actions taken on data in a domain.**
+
+**Problem:** Traditional CRUD stores only keep current state—history is lost. Audit, debugging, temporal queries, and replays are impossible without supplementary logging, which is often incomplete or out of sync.
+
+**When to use:**
+
+- You need a complete, immutable audit trail of all changes
+- The business logic benefits from replaying or projecting events into different views
+- You want to decouple the write model from the read model (often combined with CQRS)
+- You need to reconstruct past states for debugging or regulatory purposes
+
+**WAF Pillars:** Reliability, Performance Efficiency
+
+**Related patterns:** CQRS, Materialized View, Compensating Transaction, Saga
+
+---
+
+### 17. External Configuration Store
+
+**Move configuration information out of the application deployment package to a centralized location.**
+
+**Problem:** Configuration files deployed alongside the application binary require redeployment to change. Different environments (dev, staging, prod) need different values. Sharing configuration across multiple services is difficult when each has its own config file.
+
+**When to use:**
+
+- Multiple services share common configuration settings
+- You need to update configuration without redeploying or restarting services
+- You want centralized access control and audit logging for configuration
+- Configuration must differ across environments but be managed in a single system
+
+**WAF Pillars:** Operational Excellence
+
+**Related patterns:** Edge Workload Configuration, Sidecar
+
+---
+
+### 18. Federated Identity
+
+**Delegate authentication to an external identity provider.**
+
+**Problem:** Building and maintaining your own identity store introduces security risks (password storage, credential rotation, MFA implementation). Users must manage separate credentials for each application, leading to password fatigue and weaker security posture.
+
+**When to use:**
+
+- Users already have identities in an enterprise directory or social provider
+- You want to enable single sign-on (SSO) across multiple applications
+- Business partners need to access your application with their own credentials
+- You want to offload identity management (MFA, password policy) to a specialized provider
+
+**WAF Pillars:** Reliability, Security, Performance Efficiency
+
+**Related patterns:** Gatekeeper, Valet Key, Gateway Offloading
+
+---
+
+### 19. Gatekeeper
+
+**Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service.**
+
+**Problem:** Services that expose public endpoints are vulnerable to malicious attacks. Placing validation, authentication, and sanitization logic inside the service mixes security concerns with business logic and increases the attack surface if the service is compromised.
+
+**When to use:**
+
+- Applications handle sensitive data or high-value transactions
+- You need a centralized point for request validation and sanitization
+- You want to limit the attack surface by isolating security checks from the trusted host
+- Compliance requires an explicit security boundary between public and private tiers
+
+**WAF Pillars:** Security
+
+**Related patterns:** Valet Key, Gateway Routing, Gateway Offloading, Federated Identity
+
+---
+
+### 20. Gateway Aggregation
+
+**Use a gateway to aggregate multiple individual requests into a single request.**
+
+**Problem:** A client (especially mobile) may need data from multiple backend microservices to render a single page or view. Making many fine-grained calls from the client increases latency (multiple round trips), battery usage, and complexity. The client must understand the topology of the backend.
+
+**When to use:**
+
+- A client needs to make multiple calls to different backend services for a single operation
+- Network latency between the client and backend is significant (mobile, IoT, remote clients)
+- You want to reduce chattiness and simplify client code
+- Backend services are fine-grained microservices and the client should not know their topology
+
+**WAF Pillars:** Reliability, Security, Operational Excellence, Performance Efficiency
+
+**Related patterns:** Backends for Frontends, Gateway Offloading, Gateway Routing
+
+---
+
+### 21. Gateway Offloading
+
+**Offload shared or specialized service functionality to a gateway proxy.**
+
+**Problem:** Cross-cutting concerns such as TLS termination, authentication, rate limiting, logging, and compression are duplicated across every service. Each team must implement, configure, and maintain these features independently, leading to inconsistency and wasted effort.
+
+**When to use:**
+
+- Multiple services share cross-cutting concerns (TLS, auth, rate limiting, logging)
+- You want to standardize and centralize these features instead of duplicating them per service
+- You need to reduce operational complexity for individual service teams
+- The gateway is already in the request path and adding features there avoids extra hops
+
+**WAF Pillars:** Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency
+
+**Related patterns:** Gateway Aggregation, Gateway Routing, Sidecar, Ambassador
+
+---
+
+### 22. Gateway Routing
+
+**Route requests to multiple services using a single endpoint.**
+
+**Problem:** Clients must know the addresses of multiple services. Adding, removing, or relocating a service requires client updates. Exposing internal service topology increases coupling and complicates DNS and load balancing.
+
+**When to use:**
+
+- You want to expose multiple services behind a single URL with path- or header-based routing
+- You need to decouple client URLs from the internal service topology
+- You want to simplify client configuration and DNS management
+- You need to support versioned APIs or blue/green routing at the gateway level
+
+**WAF Pillars:** Reliability, Operational Excellence, Performance Efficiency
+
+**Related patterns:** Gateway Aggregation, Gateway Offloading, Backends for Frontends
+
+---
+
+### 23. Geode
+
+**Deploy backend services into a set of geographical nodes, each of which can service any client request in any region.**
+
+**Problem:** Users across the globe experience high latency when all traffic routes to a single region. A single-region deployment also creates a single point of failure and cannot meet data residency requirements for multiple jurisdictions.
+
+**When to use:**
+
+- Users are globally distributed and expect low-latency access
+- You need active-active multi-region availability
+- Data residency or sovereignty requirements mandate regional deployment
+- A single-region failure should not take down the service globally
+
+**WAF Pillars:** Reliability, Performance Efficiency
+
+**Related patterns:** Deployment Stamps, Sharding, Cache-Aside, Static Content Hosting
+
+---
+
+### 24. Health Endpoint Monitoring
+
+**Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals.**
+
+**Problem:** Without health checks, failures are detected only when users report them. Load balancers, orchestrators, and monitoring systems need a programmatic way to determine whether an instance is healthy, ready to accept traffic, and functioning correctly.
+
+**When to use:**
+
+- You use a load balancer or orchestrator (Kubernetes, App Service) that needs liveness and readiness signals
+- You want automated alerting when a service degrades
+- You need to verify downstream dependencies (database, cache, third-party API) are reachable
+- You want to enable self-healing by removing unhealthy instances from rotation
+
+**WAF Pillars:** Reliability, Operational Excellence, Performance Efficiency
+
+**Related patterns:** Circuit Breaker, Retry, Ambassador
+
+---
+
+### 25. Index Table
+
+**Create indexes over the fields in data stores that are frequently referenced by queries.**
+
+**Problem:** Many NoSQL stores support queries efficiently only on the primary or partition key. Queries on non-key fields result in full scans, which are slow and expensive at scale.
+
+**When to use:**
+
+- Queries frequently filter or sort on non-key attributes
+- The data store does not support secondary indexes natively
+- You want to trade additional storage and write overhead for faster reads
+- Read performance on secondary fields is critical to the user experience
+
+**WAF Pillars:** Reliability, Performance Efficiency
+
+**Related patterns:** Materialized View, Sharding, CQRS
+
+---
+
+### 26. Leader Election
+
+**Coordinate the actions performed by a collection of collaborating instances by electing one instance as the leader that assumes responsibility for managing the others.**
+
+**Problem:** Multiple identical instances need to coordinate shared work (aggregation, scheduling, rebalancing). Without coordination, instances may duplicate effort, conflict, or corrupt shared state.
+
+**When to use:**
+
+- A group of peer instances needs exactly one to perform coordination tasks
+- The leader must be automatically re-elected if it fails
+- You want to avoid a statically assigned coordinator that becomes a single point of failure
+- Distributed locks or consensus are needed for coordination
+
+**WAF Pillars:** Reliability
+
+**Related patterns:** Scheduler Agent Supervisor, Competing Consumers
+
+---
+
+### 27. Materialized View
+
+**Generate prepopulated views over the data in one or more data stores when the data isn't ideally formatted for required query operations.**
+
+**Problem:** The normalized storage schema that is optimal for writes is often suboptimal for complex read queries. Joins across tables or services are expensive, slow, and sometimes impossible in NoSQL stores.
+
+**When to use:**
+
+- Read queries require joining data across multiple stores or tables
+- The read pattern is well-known and relatively stable
+- You can tolerate a short delay between a write and its appearance in the view
+- You want to offload complex query logic from the application tier
+
+**WAF Pillars:** Performance Efficiency
+
+**Related patterns:** CQRS, Event Sourcing, Index Table, Cache-Aside
+
+---
+
+### 28. Messaging Bridge
+
+**Build an intermediary to enable communication between messaging systems that are otherwise incompatible, due to protocol, format, or infrastructure differences.**
+
+**Problem:** Organizations may operate multiple messaging systems (RabbitMQ, Azure Service Bus, Kafka, legacy MQ). Applications bound to different brokers cannot exchange messages natively, creating data silos and duplicated effort.
+
+**When to use:**
+
+- You need to integrate systems that use different messaging protocols or brokers
+- A migration from one messaging platform to another must be gradual
+- You want to decouple producers and consumers from a specific messaging technology
+- Interoperability between cloud and on-premises messaging is required
+
+**WAF Pillars:** Cost Optimization, Operational Excellence
+
+**Related patterns:** Anti-Corruption Layer, Publisher/Subscriber, Strangler Fig
+
+---
+
+### 29. Pipes and Filters
+
+**Decompose a task that performs complex processing into a series of separate elements that can be reused.**
+
+**Problem:** Monolithic processing pipelines are difficult to test, scale, and reuse. A single stage's failure brings down the entire pipeline. Different stages may have different scaling needs that cannot be addressed independently.
+
+**When to use:**
+
+- Processing can be broken into discrete, independent steps
+- Different steps have different scaling or deployment requirements
+- You want to reorder, add, or remove processing stages without rewriting the pipeline
+- Individual steps should be independently testable and reusable
+
+**WAF Pillars:** Reliability
+
+**Related patterns:** Competing Consumers, Queue-Based Load Leveling, Choreography
+
+---
+
+### 30. Priority Queue
+
+**Prioritize requests sent to services so that requests with a higher priority are received and processed more quickly than those with a lower priority.**
+
+**Problem:** A standard FIFO queue treats all messages equally. High-priority messages (payment confirmations, alerts) wait behind low-priority messages (reports, analytics), degrading the experience for critical operations.
+
+**When to use:**
+
+- The system serves multiple clients or tenants with different SLAs
+- Certain message types must be processed within tighter time bounds
+- You need to guarantee that premium or critical workloads are not starved
+- Different priorities map to different processing costs or deadlines
+
+**WAF Pillars:** Reliability, Performance Efficiency
+
+**Related patterns:** Competing Consumers, Queue-Based Load Leveling, Throttling
+
+---
+
+### 31. Publisher/Subscriber
+
+**Enable an application to announce events to multiple interested consumers asynchronously, without coupling the senders to the receivers.**
+
+**Problem:** A service that must notify multiple consumers directly becomes tightly coupled to each consumer. Adding a new consumer requires changing the producer. Synchronous calls from the producer to each consumer increase latency and reduce availability.
+
+**When to use:**
+
+- Multiple consumers need to react to the same event independently
+- Producers and consumers should evolve independently
+- You need to add new consumers without modifying the producer
+- The system benefits from temporal decoupling (consumers process events at their own pace)
+
+**WAF Pillars:** Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency
+
+**Related patterns:** Choreography, Competing Consumers, Event Sourcing, Queue-Based Load Leveling
+
+---
+
+### 32. Quarantine
+
+**Ensure external assets meet a team-agreed quality level before being authorized for consumption.**
+
+**Problem:** External artifacts (container images, packages, data files, IaC modules) may contain vulnerabilities, malware, or misconfigurations. Consuming them without validation exposes the system to supply-chain attacks and compliance violations.
+
+**When to use:**
+
+- You consume third-party container images, packages, or libraries
+- Compliance requires scanning artifacts before deployment
+- You want to gate promotion of artifacts through quality tiers (untested → tested → approved)
+- You need traceability for which version of an external asset is deployed
+
+**WAF Pillars:** Security, Operational Excellence
+
+**Related patterns:** Gatekeeper, Gateway Offloading, Pipes and Filters
+
+---
+
+### 33. Queue-Based Load Leveling
+
+**Use a queue that acts as a buffer between a task and a service it invokes, to smooth intermittent heavy loads.**
+
+**Problem:** Spikes in demand can overwhelm a service, causing throttling, errors, or outages. Over-provisioning to handle peak load wastes resources during normal periods.
+
+**When to use:**
+
+- The workload is bursty but the backend service scales slowly or is expensive to over-provision
+- You need to decouple the rate at which work is submitted from the rate at which it is processed
+- You want to flatten traffic spikes without losing requests
+- Temporary unavailability of the backend should not result in data loss
+
+**WAF Pillars:** Reliability, Cost Optimization, Performance Efficiency
+
+**Related patterns:** Competing Consumers, Priority Queue, Throttling, Bulkhead
+
+---
+
+### 34. Rate Limiting
+
+**Control the rate of requests a client or service can send to or receive from another service, to prevent overconsumption of resources.**
+
+**Problem:** Without rate limiting, a misbehaving or compromised client can exhaust backend resources, causing service degradation for all consumers. Uncontrolled traffic can also trigger cloud provider throttling or incur excessive costs.
+
+**When to use:**
+
+- You need to protect shared resources from overconsumption
+- You want to enforce fair usage across tenants or clients
+- The backend has known capacity limits and you want to stay below them
+- You need to prevent cascade failures caused by sudden traffic surges
+
+**WAF Pillars:** Reliability
+
+**Related patterns:** Throttling, Bulkhead, Circuit Breaker, Queue-Based Load Leveling
+
+---
+
+### 35. Retry
+
+**Enable an application to handle anticipated, temporary failures when it tries to connect to a service or network resource, by transparently retrying a failed operation.**
+
+**Problem:** Cloud environments experience transient faults—brief network glitches, service restarts, temporary throttling. If the application treats every failure as permanent, it unnecessarily degrades the user experience or triggers costly failovers.
+
+**When to use:**
+
+- The failure is likely transient (HTTP 429, 503, timeout)
+- Retrying the same request is idempotent or safe
+- You want to improve resilience without complex failover infrastructure
+- The downstream service is expected to recover within a short window
+
+**WAF Pillars:** Reliability
+
+**Related patterns:** Circuit Breaker, Bulkhead, Ambassador, Health Endpoint Monitoring
+
+---
+
+### 36. Saga
+
+**Manage data consistency across microservices in distributed transaction scenarios.**
+
+**Problem:** Traditional distributed transactions (two-phase commit) are not feasible across microservices with independent databases. Without a coordination mechanism, partial failures leave the system in an inconsistent state.
+
+**When to use:**
+
+- A business operation spans multiple microservices, each with its own data store
+- You need eventual consistency with well-defined compensating actions
+- Two-phase commit is not available or would introduce unacceptable coupling
+- Each step can be reversed by a compensating transaction
+
+**WAF Pillars:** Reliability
+
+**Related patterns:** Compensating Transaction, Choreography, Scheduler Agent Supervisor, Event Sourcing
+
+---
+
+### 37. Scheduler Agent Supervisor
+
+**Coordinate a set of distributed actions as a single operation. If any of the actions fail, try to handle the failures transparently, or else undo the work that was performed.**
+
+**Problem:** Distributed workflows involve multiple steps across different services. You need a way to track progress, detect failures, retry or compensate, and ensure the workflow reaches a terminal state.
+
+**When to use:**
+
+- A workflow spans multiple remote services that must be orchestrated
+- You need centralized monitoring and control of workflow progress
+- Failures should be retried or compensated automatically
+- The workflow must guarantee completion or rollback
+
+**WAF Pillars:** Reliability, Performance Efficiency
+
+**Related patterns:** Saga, Compensating Transaction, Leader Election, Retry
+
+---
+
+### 38. Sequential Convoy
+
+**Process a set of related messages in a defined order, without blocking processing of other groups of messages.**
+
+**Problem:** Message ordering is required within a logical group (e.g., all events for a single order), but a strict global order would serialize the entire system and destroy throughput. Different groups are independent and can be processed in parallel.
+
+**When to use:**
+
+- Messages within a group must be processed in order (e.g., order events, session events)
+- Different groups can be processed concurrently
+- Out-of-order processing within a group would cause data corruption or incorrect results
+- You need high throughput across groups while preserving per-group ordering
+
+**WAF Pillars:** Reliability
+
+**Related patterns:** Competing Consumers, Priority Queue, Queue-Based Load Leveling
+
+---
+
+### 39. Sharding
+
+**Divide a data store into a set of horizontal partitions or shards.**
+
+**Problem:** A single database server has finite storage, compute, and I/O capacity. As data volume and query load grow, vertical scaling becomes prohibitively expensive or hits hardware limits. A single server is also a single point of failure.
+
+**When to use:**
+
+- A single data store cannot handle the storage or throughput requirements
+- You need to distribute data geographically for latency or compliance
+- You want to scale horizontally by adding more nodes
+- Different subsets of data have different access patterns or SLAs
+
+**WAF Pillars:** Reliability, Cost Optimization
+
+**Related patterns:** Index Table, Materialized View, Geode, Deployment Stamps
+
+---
+
+### 40. Sidecar
+
+**Deploy components of an application into a separate process or container to provide isolation and encapsulation.**
+
+**Problem:** Applications need cross-cutting functionality (logging, monitoring, configuration, networking). Embedding these directly into the application creates tight coupling, language lock-in, and shared failure domains.
+
+**When to use:**
+
+- The cross-cutting component must run alongside the main application but in isolation
+- The main application and the sidecar can be developed in different languages
+- You want to extend or add functionality without modifying the main application
+- The sidecar has a different lifecycle or scaling requirement than the main application
+
+**WAF Pillars:** Security, Operational Excellence
+
+**Related patterns:** Ambassador, Gateway Offloading, Compute Resource Consolidation
+
+---
+
+### 41. Static Content Hosting
+
+**Deploy static content to a cloud-based storage service that can deliver them directly to the client.**
+
+**Problem:** Serving static files (images, scripts, stylesheets, documents) from the application server wastes compute that should be reserved for dynamic content. It also limits scalability and increases cost.
+
+**When to use:**
+
+- The application serves static files that do not change per request
+- You want to reduce the load on your web servers
+- A CDN can accelerate delivery to geographically distributed users
+- You want cost-effective, highly available static file hosting
+
+**WAF Pillars:** Cost Optimization
+
+**Related patterns:** Valet Key, Geode, Cache-Aside
+
+---
+
+### 42. Strangler Fig
+
+**Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services.**
+
+**Problem:** Rewriting a large legacy system from scratch is risky, expensive, and often fails. The legacy system must continue operating during the migration. A big-bang cutover is not feasible due to risk and business continuity requirements.
+
+**When to use:**
+
+- You are replacing a monolithic legacy application incrementally
+- You need the old and new systems to coexist during migration
+- You want to reduce migration risk by delivering value incrementally
+- The legacy system is too large or complex for a single-phase replacement
+
+**WAF Pillars:** Reliability, Cost Optimization, Operational Excellence
+
+**Related patterns:** Anti-Corruption Layer, Gateway Routing, Sidecar
+
+---
+
+### 43. Throttling
+
+**Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service.**
+
+**Problem:** Sudden spikes in demand or a misbehaving tenant can exhaust shared resources, degrading the experience for all users. Over-provisioning to handle worst-case load is expensive and wasteful.
+
+**When to use:**
+
+- You need to enforce SLAs or quotas per tenant in a multi-tenant system
+- The backend has known capacity limits and exceeding them causes instability
+- You want to degrade gracefully under load rather than fail entirely
+- You need to prevent a single workload from monopolizing shared resources
+
+**WAF Pillars:** Reliability, Security, Cost Optimization, Performance Efficiency
+
+**Related patterns:** Rate Limiting, Bulkhead, Queue-Based Load Leveling, Priority Queue
+
+---
+
+### 44. Valet Key
+
+**Use a token or key that provides clients with restricted direct access to a specific resource or service.**
+
+**Problem:** Routing all data transfers through the application server creates a bottleneck and increases cost. Giving clients direct access to the data store without any restriction is a security risk.
+
+**When to use:**
+
+- You want to minimize the load on the application server for data-intensive transfers (uploads/downloads)
+- You need to grant time-limited, scope-limited access to a specific resource
+- You want to offload transfer bandwidth to a storage service (Blob Storage, S3)
+- Clients need temporary access without full credentials to the data store
+
+**WAF Pillars:** Security, Cost Optimization, Performance Efficiency
+
+**Related patterns:** Gatekeeper, Static Content Hosting, Federated Identity
+
+---
+
+> Source: [Azure Architecture Center — Cloud Design Patterns](https://learn.microsoft.com/en-us/azure/architecture/patterns/)