Cloud Design Patterns — cheat sheet
A one-page lookup for the concepts used across this course. Grouped by task; the course pages cover the
why behind each one — this page is just the what.
Availability
| Task |
Reach for |
| Knowing whether an instance can serve traffic right now |
a health check endpoint (liveness vs. readiness) |
| Spreading requests across healthy instances |
a load balancer, routing around unhealthy ones |
| Surviving a whole data center failure |
multi-AZ — spread instances across Availability Zones |
Resiliency
| Task |
Reach for |
| A call fails transiently |
retry with backoff — space out and cap the attempts |
| A dependency is consistently failing |
a circuit breaker — fail fast, stop hammering it, let it recover |
| One slow dependency shouldn't starve calls to another |
a bulkhead — isolate resource pools per dependency |
| A call might hang forever |
a timeout — bound the maximum wait on every outbound call |
| Avoiding a retry storm |
pick ONE layer (app, service mesh (module 22)) to own retries for a call path |
Scalability
| Task |
Reach for |
| Matching capacity to real, sustained demand |
autoscaling, driven by a real signal (CPU, request rate, queue depth) |
| Absorbing a short burst faster than autoscaling can react |
queue-based load leveling |
| Reducing repeated load on a primary data store |
cache-aside — read cache first, populate on a miss |
Management and monitoring
| Task |
Reach for |
| Seeing instance-level health beyond load-balancer routing |
health endpoint monitoring — the same check, a second audience |
| Changing a runtime setting without a rebuild/redeploy |
an external configuration store |
| Deciding availability vs. cost tradeoffs generally |
AWS/Azure Well-Architected pattern vocabulary — the terms on this page |
How this connects
Availability patterns (page 1) keep the system serving traffic through instance and data-center failures;
resiliency patterns (page 2) keep one failing dependency from cascading into a bigger outage; scalability
patterns (page 3) handle load growing beyond current capacity; management and monitoring patterns (page 4)
are how operators see system state and change runtime behavior without a redeploy. Together they're the
standard vocabulary (AWS Well-Architected Framework, Azure Architecture Center) for reasoning about a
distributed system's behavior under real-world failure and load — the same concerns
module 04, Kubernetes & Helm,
module 05, AWS, and
module 17, Observability implement the mechanics for.