| name | cloud-design-patterns |
| version | 2.0 |
| last_updated | 2026-08-29T00:00:00.000Z |
| tags | ["cloud","design","patterns","architecture","operations"] |
| description | Choose and compare cloud design patterns for distributed systems. Use when reviewing architecture, selecting workload patterns, or mapping reliability, performance, messaging, security, and migration concerns to concrete design options. |
Cloud Design Patterns
Use proven distributed-systems patterns to choose safer architectures and surface trade-offs early.
- Leverage native parallel subagent dispatch and 200k+ context windows where available.
When to Use
Use symptom -> action triggers: when one matches, apply this skill and verify with the protocol below.
- You are designing or reviewing a cloud or distributed-system architecture.
- A workload has reliability, latency, scaling, messaging, migration, or security concerns.
- You need to shortlist patterns before writing an ADR, design doc, or implementation plan.
- You want a technology-agnostic pattern discussion before choosing platform services.
Pattern Selection Workflow
- State the main workload goal and the main constraint.
- Identify the top concerns: reliability, performance, messaging, migration, deployment, security, or eventing.
- Use the concern-to-pattern map below to shortlist candidates.
- Compare trade-offs instead of looking for a single perfect pattern.
- Document why the chosen pattern fits the workload better than the obvious alternatives.
Concern-To-Pattern Map
| Concern | Common patterns | Reference |
|---|
| reliability and fault tolerance | Bulkhead, Circuit Breaker, Retry, Health Endpoint Monitoring, Saga | Reliability And Resilience |
| performance and scale | Cache-Aside, CQRS, Queue-Based Load Leveling, Rate Limiting, Sharding | Performance |
| messaging and workflow coordination | Publisher-Subscriber, Pipes and Filters, Competing Consumers, Choreography | Messaging And Integration |
| architecture boundaries and API shape | Anti-Corruption Layer, Backends for Frontends, Gateway patterns, Sidecar, Strangler Fig | Architecture And Design |
| deployment and operations | Deployment Stamps, External Configuration Store, Geode, Static Content Hosting | Deployment And Operational |
| security and controlled access | Federated Identity, Quarantine, Valet Key | Security |
| event sourcing and auditability | Event Sourcing | Event-Driven |
Pattern Review Questions
Ask these before locking in a pattern:
- What failure mode is this pattern reducing?
- What cost, complexity, or operational burden does it add?
- Does the team have the observability needed to operate it?
- Is the pattern local to one subsystem or does it create a cross-cutting contract?
- What simpler alternative did we reject, and why?
Anti-Patterns
- Changing infrastructure before inspecting the current state: Cloud drift and hidden dependencies make blind edits risky.
- Hardcoding credentials or environment assumptions: Rollouts stop being reproducible and secrets become harder to rotate.
- Skipping rollback, observability, or validation planning: You only notice the missing safeguards after the deployment is already live.
Verification Protocol
Before claiming "skill applied successfully":
- Pass/fail: The Cloud Design Patterns workflow starts from explicit success criteria, constraints, and stop conditions.
- Pass/fail: Required evidence is collected before any completion, approval, or readiness claim.
- Pass/fail: The next action follows the documented gate order without skipping review or verification steps.
- Pressure-test scenario: Apply the workflow under time pressure with one failing check and one tempting shortcut.
- Success metric: Zero rationalizations; blocked, failed, or unverified work is reported as such.
Scripts And References
Practical Guidance
- Prefer a small pattern set that directly addresses the workload constraints.
- Pair each selected pattern with explicit observability and rollback thinking.
- Technology choice comes after pattern choice, not before it.
- If a migration is underway, keep the transitional pattern and the target steady-state pattern separate in your notes.
Cross-Client Portability
This skill is written to stay usable across GitHub Copilot, Claude Code, and Codex.
- GitHub Copilot: keep the folder in a Copilot-visible skill path or wrap the
workflow in project instructions when folder discovery is unavailable.
- Claude Code: keep the folder in a local skills directory or a compatible plugin source.
- Codex: install or sync the folder into
$CODEX_HOME/skills/cloud-design-patterns and restart Codex after major changes.
MCP Availability And Fallback
Preferred MCP Server: None required
- Fallback prompt: "Use the Cloud Design Patterns skill without MCP. Rely on the local
SKILL.md, bundled references or scripts, and manual verification. Show the exact commands, evidence, and final checks you used before concluding."
- If the current host does not expose a matching server, use the bundled references, scripts, native toolchain, and manual workflow already described in this skill.
- Treat direct local verification, rendered output, logs, tests, or screenshots as the fallback evidence path before completion.
Related Skills
- azure-integrations: Use it when the workflow also needs Azure deployment and infrastructure automation.
- powerbi-modeling: Use it when the workflow also needs Power BI semantic model design and DAX work.
- microsoft-development: Use it when the workflow also needs microsoft development guidance.
- sql-development: Use it when the workflow also needs SQL query, schema, and performance tuning work.
