github · fatihdurgut · Mar 9, 2026 · Mar 11, 2026 · Mar 11, 2026 · Mar 11, 2026
@@ -56,6 +56,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [centos-linux-triage](../skills/centos-linux-triage/SKILL.md) | Triage and resolve CentOS issues using RHEL-compatible tooling, SELinux-aware practices, and firewalld. | None |
 | [chrome-devtools](../skills/chrome-devtools/SKILL.md) | Expert-level browser automation, debugging, and performance analysis using Chrome DevTools MCP. Use for interacting with web pages, capturing screenshots, analyzing network traffic, and profiling performance. | None |
 | [cli-mastery](../skills/cli-mastery/SKILL.md) | Interactive training for the GitHub Copilot CLI. Guided lessons, quizzes, scenario challenges, and a full reference covering slash commands, shortcuts, modes, agents, skills, MCP, and configuration. Say "cliexpert" to start. | `references/final-exam.md`<br />`references/module-1-slash-commands.md`<br />`references/module-2-keyboard-shortcuts.md`<br />`references/module-3-modes.md`<br />`references/module-4-agents.md`<br />`references/module-5-skills.md`<br />`references/module-6-mcp.md`<br />`references/module-7-advanced.md`<br />`references/module-8-configuration.md`<br />`references/scenarios.md` |
+| [cloud-design-patterns](../skills/cloud-design-patterns/SKILL.md) | Cloud design patterns for distributed systems architecture covering 42 industry-standard patterns across reliability, performance, messaging, security, and deployment categories. Use when designing, reviewing, or implementing distributed system architectures. | `references/architecture-design.md`<br />`references/azure-service-mappings.md`<br />`references/best-practices.md`<br />`references/deployment-operational.md`<br />`references/event-driven.md`<br />`references/messaging-integration.md`<br />`references/performance.md`<br />`references/reliability-resilience.md`<br />`references/security.md` |
 | [code-exemplars-blueprint-generator](../skills/code-exemplars-blueprint-generator/SKILL.md) | Technology-agnostic prompt generator that creates customizable AI prompts for scanning codebases and identifying high-quality code exemplars. Supports multiple programming languages (.NET, Java, JavaScript, TypeScript, React, Angular, Python) with configurable analysis depth, categorization methods, and documentation formats to establish coding standards and maintain consistency across development teams. | None |
 | [comment-code-generate-a-tutorial](../skills/comment-code-generate-a-tutorial/SKILL.md) | Transform this Python script into a polished, beginner-friendly project by refactoring the code, adding clear instructional comments, and generating a complete markdown tutorial. | None |
 | [containerize-aspnet-framework](../skills/containerize-aspnet-framework/SKILL.md) | Containerize an ASP.NET .NET Framework project by creating Dockerfile and .dockerfile files customized for the project. | None |

@@ -0,0 +1,62 @@
+---
+name: cloud-design-patterns
+description: 'Cloud design patterns for distributed systems architecture covering 42 industry-standard patterns across reliability, performance, messaging, security, and deployment categories. Use when designing, reviewing, or implementing distributed system architectures.'
+---
+
+# Cloud Design Patterns
+
+Architects design workloads by integrating platform services, functionality, and code to meet both functional and nonfunctional requirements. To design effective workloads, you must understand these requirements and select topologies and methodologies that address the challenges of your workload's constraints. Cloud design patterns provide solutions to many common challenges.
+
+System design heavily relies on established design patterns. You can design infrastructure, code, and distributed systems by using a combination of these patterns. These patterns are crucial for building reliable, highly secure, cost-optimized, operationally efficient, and high-performing applications in the cloud.
+
+The following cloud design patterns are technology-agnostic, which makes them suitable for any distributed system. You can apply these patterns across Azure, other cloud platforms, on-premises setups, and hybrid environments.
+
+## How Cloud Design Patterns Enhance the Design Process
+
+Cloud workloads are vulnerable to the fallacies of distributed computing, which are common but incorrect assumptions about how distributed systems operate. Examples of these fallacies include:
+
+- The network is reliable.
+- Latency is zero.
+- Bandwidth is infinite.
+- The network is secure.
+- Topology doesn't change.
+- There's one administrator.
+- Component versioning is simple.
+- Observability implementation can be delayed.
+
+These misconceptions can result in flawed workload designs. Design patterns don't eliminate these misconceptions but help raise awareness, provide compensation strategies, and provide mitigations. Each cloud design pattern has trade-offs. Focus on why you should choose a specific pattern instead of how to implement it.
+
+---
+
+## References
+
+| Reference | When to load |
+|---|---|
+| [Reliability & Resilience Patterns](references/reliability-resilience.md) | Ambassador, Bulkhead, Circuit Breaker, Compensating Transaction, Retry, Health Endpoint Monitoring, Leader Election, Saga, Sequential Convoy |
+| [Performance Patterns](references/performance.md) | Async Request-Reply, Cache-Aside, CQRS, Index Table, Materialized View, Priority Queue, Queue-Based Load Leveling, Rate Limiting, Sharding, Throttling |
+| [Messaging & Integration Patterns](references/messaging-integration.md) | Choreography, Claim Check, Competing Consumers, Messaging Bridge, Pipes and Filters, Publisher-Subscriber, Scheduler Agent Supervisor |
+| [Architecture & Design Patterns](references/architecture-design.md) | Anti-Corruption Layer, Backends for Frontends, Gateway Aggregation/Offloading/Routing, Sidecar, Strangler Fig |
+| [Deployment & Operational Patterns](references/deployment-operational.md) | Compute Resource Consolidation, Deployment Stamps, External Configuration Store, Geode, Static Content Hosting |
+| [Security Patterns](references/security.md) | Federated Identity, Quarantine, Valet Key |
+| [Event-Driven Architecture Patterns](references/event-driven.md) | Event Sourcing |
+| [Best Practices & Pattern Selection](references/best-practices.md) | Selecting appropriate patterns, Well-Architected Framework alignment, documentation, monitoring |
+| [Azure Service Mappings](references/azure-service-mappings.md) | Common Azure services for each pattern category |
+
+---
+
+## Pattern Categories at a Glance
+
+| Category | Patterns | Focus |
+|---|---|---|
+| Reliability & Resilience | 9 patterns | Fault tolerance, self-healing, graceful degradation |
+| Performance | 10 patterns | Caching, scaling, load management, data optimization |
+| Messaging & Integration | 7 patterns | Decoupling, event-driven communication, workflow coordination |
+| Architecture & Design | 7 patterns | System boundaries, API gateways, migration strategies |
+| Deployment & Operational | 5 patterns | Infrastructure management, geo-distribution, configuration |
+| Security | 3 patterns | Identity, access control, content validation |
+| Event-Driven Architecture | 1 pattern | Event sourcing and audit trails |
+
+## External Links
+
+- [Cloud Design Patterns - Azure Architecture Center](https://learn.microsoft.com/azure/architecture/patterns/)
+- [Azure Well-Architected Framework](https://learn.microsoft.com/azure/architecture/framework/)
@@ -0,0 +1,127 @@
+# Architecture & Design Patterns
+
+## Anti-Corruption Layer Pattern
+
+**Problem**: New systems must integrate with legacy systems that use outdated models or technologies.
+
+**Solution**: Implement a façade or adapter layer between a modern application and a legacy system to prevent legacy constraints from affecting new design.
+
+**When to Use**:
+- Migrating from legacy systems incrementally
+- Integrating with third-party systems with different domain models
+- Protecting modern architectures from legacy constraints
+
+**Implementation Considerations**:
+- Create translation layer between domain models
+- Map between legacy and modern data structures
+- Isolate legacy system interfaces behind abstractions
+- Consider performance impact of translation
+- Plan for eventual removal if migration is complete
+
+## Backends for Frontends (BFF) Pattern
+
+**Problem**: A single backend may not optimally serve different client types.
+
+**Solution**: Create separate backend services to serve specific frontend applications or interfaces.
+
+**When to Use**:
+- Different client types (web, mobile, IoT) have different needs
+- Optimizing payload size and shape per client
+- Reducing coupling between frontend and shared backend
+
+**Implementation Considerations**:
+- Create one BFF per user experience or client type
+- Tailor API contracts to frontend needs
+- Avoid duplicating business logic across BFFs
+- Share common services between BFFs
+- Manage increased number of services
+
+## Gateway Aggregation Pattern
+
+**Problem**: Clients need data from multiple backend services.
+
+**Solution**: Use a gateway to aggregate multiple individual requests into a single request.
+
+**When to Use**:
+- Reducing chattiness between clients and backends
+- Combining data from multiple sources for a single view
+- Reducing latency by parallelizing backend calls
+
+**Implementation Considerations**:
+- API gateway aggregates responses from multiple services
+- Execute backend calls in parallel where possible
+- Handle partial failures appropriately
+- Consider caching of aggregated responses
+- Avoid creating a monolithic gateway
+
+## Gateway Offloading Pattern
+
+**Problem**: Shared functionality is duplicated across multiple services.
+
+**Solution**: Offload shared or specialized service functionality to a gateway proxy.
+
+**When to Use**:
+- Centralizing cross-cutting concerns (SSL, authentication, logging)
+- Simplifying service implementation
+- Standardizing shared functionality
+
+**Implementation Considerations**:
+- Offload SSL termination to gateway
+- Implement authentication and authorization at gateway
+- Handle rate limiting and throttling
+- Provide request/response logging
+- Avoid making gateway a bottleneck
+
+## Gateway Routing Pattern
+
+**Problem**: Clients need to access multiple services through a single endpoint.
+
+**Solution**: Route requests to multiple services using a single endpoint.
+
+**When to Use**:
+- Providing a single entry point for multiple services
+- Abstracting backend service topology from clients
+- Enabling service versioning and migration strategies
+
+**Implementation Considerations**:
+- Route based on URL path, headers, or query parameters
+- Support URL rewriting and transformation
+- Enable A/B testing and canary deployments
+- Implement health checks for backend services
+- Monitor routing performance
+
+## Sidecar Pattern
+
+**Problem**: Applications need auxiliary functionality without coupling.
+
+**Solution**: Deploy components of an application into a separate process or container to provide isolation and encapsulation.
+
+**When to Use**:
+- Adding functionality to applications without modifying them
+- Implementing cross-cutting concerns (logging, monitoring, security)
+- Supporting heterogeneous environments
+
+**Implementation Considerations**:
+- Deploy sidecar alongside main application
+- Share lifecycle, resources, and network with main application
+- Use for proxying, logging, configuration, or monitoring
+- Consider resource overhead of additional containers
+- Standardize sidecar implementations across services
+
+## Strangler Fig Pattern
+
+**Problem**: Legacy systems are risky to replace all at once.
+
+**Solution**: Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services.
+
+**When to Use**:
+- Modernizing legacy applications
+- Reducing risk of big-bang migrations
+- Enabling incremental business value delivery
+
+**Implementation Considerations**:
+- Identify functionality to migrate incrementally
+- Use facade or proxy to route between old and new
+- Migrate less risky components first
+- Run old and new systems in parallel initially
+- Plan for eventual decommissioning of legacy system
@@ -0,0 +1,13 @@
+# Azure Service Mappings
+
+## Common Azure Services per Pattern
+
+- **Message Queue**: Azure Service Bus, Azure Storage Queue, Event Hubs
+- **Cache**: Azure Cache for Redis, Azure Front Door cache
+- **API Gateway**: Azure API Management, Azure Application Gateway
+- **Identity**: Azure AD, Azure AD B2C
+- **Configuration**: Azure App Configuration, Azure Key Vault
+- **Storage**: Azure Storage (Blob, Table, Queue), Azure Cosmos DB
+- **Compute**: Azure Functions, Azure Container Apps, Azure Kubernetes Service
+- **Event Streaming**: Azure Event Hubs, Azure Event Grid
+- **CDN**: Azure CDN, Azure Front Door
@@ -0,0 +1,34 @@
+# Best Practices for Pattern Selection
+
+## Selecting Appropriate Patterns
+
+- **Understand the problem**: Clearly identify the specific challenge before choosing a pattern
+- **Consider trade-offs**: Each pattern introduces complexity and trade-offs
+- **Combine patterns**: Many patterns work better together (Circuit Breaker + Retry, CQRS + Event Sourcing)
+- **Start simple**: Don't over-engineer; apply patterns when the need is clear
+- **Platform-specific**: Consider Azure services that implement patterns natively
+
+## Well-Architected Framework Alignment
+
+Map selected patterns to Well-Architected Framework pillars:
+- **Reliability**: Circuit Breaker, Bulkhead, Retry, Health Endpoint Monitoring
+- **Security**: Federated Identity, Valet Key, Gateway Offloading, Quarantine
+- **Cost Optimization**: Compute Resource Consolidation, Static Content Hosting, Throttling
+- **Operational Excellence**: External Configuration Store, Sidecar, Deployment Stamps
+- **Performance Efficiency**: Cache-Aside, CQRS, Materialized View, Sharding
+
+## Pattern Documentation
+
+When implementing patterns, document:
+- Which pattern is being used and why
+- Trade-offs accepted
+- Configuration and tuning parameters
+- Monitoring and observability approach
+- Failure scenarios and recovery procedures
+
+## Monitoring Patterns
+
+- Implement comprehensive observability for all patterns
+- Track pattern-specific metrics (circuit breaker state, cache hit ratio, queue depth)
+- Use distributed tracing for patterns involving multiple services
+- Alert on pattern degradation (circuit frequently open, high retry rates)
@@ -0,0 +1,91 @@
+# Deployment & Operational Patterns
+
+## Compute Resource Consolidation Pattern
+
+**Problem**: Multiple tasks consume resources inefficiently when isolated.
+
+**Solution**: Consolidate multiple tasks or operations into a single computational unit.
+
+**When to Use**:
+- Reducing infrastructure costs
+- Improving resource utilization
+- Simplifying deployment and management
+
+**Implementation Considerations**:
+- Group related tasks with similar scaling requirements
+- Use containers or microservices hosting
+- Monitor resource usage per task
+- Ensure isolation where needed for security/reliability
+- Balance between consolidation and failure isolation
+
+## Deployment Stamps Pattern
+
+**Problem**: Applications need to scale across regions or customer segments.
+
+**Solution**: Deploy multiple independent copies of application components (stamps), including data stores, to serve different regions or customer segments.
+
+**When to Use**:
+- Scaling beyond single stamp limits
+- Providing regional data residency
+- Isolating tenants for security or performance
+
+**Implementation Considerations**:
+- Each stamp is a complete, self-contained deployment
+- Deploy stamps across regions for geo-distribution
+- Route requests to appropriate stamp
+- Manage stamp deployments consistently (IaC)
+- Plan for stamp capacity and when to add new stamps
+
+## External Configuration Store Pattern
+
+**Problem**: Application configuration is embedded in deployment packages.
+
+**Solution**: Move configuration information out of the application deployment package to a centralized location.
+
+**When to Use**:
+- Managing configuration across multiple environments
+- Updating configuration without redeployment
+- Sharing configuration across multiple applications
+
+**Implementation Considerations**:
+- Use Azure App Configuration, Key Vault, or similar services
+- Implement configuration change notifications
+- Cache configuration locally to reduce dependencies
+- Secure sensitive configuration (connection strings, secrets)
+- Version configuration changes
+
+## Geode Pattern
+
+**Problem**: Users in different regions experience high latency.
+
+**Solution**: Deploy backend services into a set of geographical nodes, each of which can service any client request in any region.
+
+**When to Use**:
+- Reducing latency for globally distributed users
+- Providing high availability across regions
+- Implementing active-active geo-distribution
+
+**Implementation Considerations**:
+- Deploy application instances in multiple regions
+- Replicate data globally (consider consistency implications)
+- Route users to nearest healthy region
+- Implement conflict resolution for multi-master writes
+- Monitor regional health and performance
+
+## Static Content Hosting Pattern
+
+**Problem**: Serving static content from compute instances is inefficient.
+
+**Solution**: Deploy static content to a cloud-based storage service that can deliver content directly to the client.
+
+**When to Use**:
+- Hosting images, videos, CSS, JavaScript files
+- Reducing load on web servers
+- Improving content delivery performance
+
+**Implementation Considerations**:
+- Use blob storage, CDN, or static website hosting
+- Enable CORS for cross-origin access
+- Implement caching headers appropriately
+- Use CDN for global content distribution
+- Secure content with SAS tokens if needed
@@ -0,0 +1,21 @@
+# Event-Driven Architecture Patterns
+
+## Event Sourcing Pattern
+
+**Problem**: Need complete audit trail of all changes to application state.
+
+**Solution**: Use an append-only store to record the full series of events that describe actions taken on data in a domain.
+
+**When to Use**:
+- Requiring complete audit trail
+- Implementing temporal queries (point-in-time state)
+- Supporting event replay and debugging
+- Implementing CQRS with eventual consistency
+
+**Implementation Considerations**:
+- Store events in append-only log
+- Rebuild current state by replaying events
+- Implement event versioning strategy
+- Handle event schema evolution
+- Consider storage growth over time
+- Implement snapshots for performance