Azure Architecture Patterns

These design patterns are useful for building reliable, scalable, secure applications in the cloud.

Each pattern describes the problem that the pattern addresses, considerations for applying the pattern, and an example based on Microsoft Azure. Most of the patterns include code samples or snippets that show how to implement the pattern on Azure. However, most of the patterns are relevant to any distributed system, whether hosted on Azure or on other cloud platforms.


MS: Pillars of Software Quality


Shared Services Examples

Infrastructure Patterns

mnemonic: FGVS: F*ing Great Valet Hosting

  1. Federated Identity Pattern: Example: Logging into Azure AD/ ADFS into any kind of service.

  2. Gatekeeper Pattern: A security instance acts as a gatekeeper. Example: a reverse proxy layer (Application Gateway, Front Door), with web application firewall (waf) enabled, that protects my application from attack.

  3. Valet Key Pattern. Example: File uploads. Instead of giving you a storage key, I give you a shared access signature to only upload to that one blob. Refer

  4. Static Content Hosting Pattern: Example: a CDN handling caching of content

App Scalability Patterns

mnemonic: Competes with CQRS

  1. Queue Based Load Levelling Pattern: you are in a Q
  2. Competing Consumers Pattern: Implement when #1 fails: if I have a really long Q and only 1 instance processing it, the Q becomes a bottleneck: then add more instances of consumers
  3. CQRS pattern

Reliability & Performance Patterns

Throttle & Break Cache

  1. Throttling: Design to a certain performance level. Over and beyond this level, fail with “too many requests”. APIM policy can be used to throttle excessive requests.
  2. Circuit Breaker Pattern: Opposite of retry pattern. I know that service is down; no point retrying as it is never going to work. Wait when it is back up and then retry.
  3. Cache Aside Pattern: Redis. Look to see if data is in cache first before hitting storage. If data not in cache, get from storage and also put in cache. If another instance then writes to the storage, notify all cache consumers that cache has changed and flush the cache. Effect: you will never have stale data because the next request that will be made will read fresh data from storage and will put fresh data back in the cache.

Storage Patterns

Materialized View Pattern

Static Content Hosting Pattern


Options simpler than CQRS for Geo Replication



MS: Pillars of Software Quality