Cloud Solution Architect

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