Cloud Design Patterns

Core (the standard vocabulary for reasoning about distributed-system tradeoffs on any real engagement, not an optional extra). · prereq 04 (Orchestration · Kubernetes & Helm), 05 (Cloud · AWS), 17 (Observability & Monitoring) — these patterns are the reasoning behind decisions module 04 (Kubernetes) and module 05 (AWS) already let you implement mechanically, and several (health checks, per-instance metrics) feed directly into module 17 (Observability & Monitoring)'s monitoring stack. · ~1 day (4 reference submodules — availability, resiliency, scalability, and management/monitoring patterns). Reality check: this is the 80/20 on-ramp; real fluency (correctly choosing and combining these patterns under a specific team's actual failure modes and traffic) is built on the job.

Module 04 (Kubernetes), module 05 (AWS), and module 17 (Observability & Monitoring) give you the mechanics — pods, managed services, dashboards. This module gives you the vocabulary for what to actually build with those mechanics: the standard, technology-agnostic patterns for staying available through failure, staying resilient when one dependency breaks, and scaling with real demand instead of a fixed, hand-sized fleet.

TL;DR — in 30 seconds:

• Availability patterns (health checks, load balancing, multi-AZ) keep the system serving traffic when an individual instance — or a whole data center — fails.
• Resiliency patterns (retry-with-backoff, circuit breaker, bulkhead, timeout) keep one failing dependency from cascading into a bigger outage on the caller.
• Scalability patterns (autoscaling, queue-based load leveling, cache-aside) handle load growing beyond what's currently provisioned, at three different points in the system.
• Management/monitoring patterns (health endpoint monitoring, external configuration store) are how operators see system state and change runtime behavior without a redeploy.
• These aren't SE inventions — they're the standard vocabulary of the AWS Well-Architected Framework and Azure Architecture Center's cloud design pattern catalog, so the terms transfer to any cloud.

Learning objectives

By the end, the junior can:

• Explain what a health check actually verifies, how a load balancer uses it, and why multi-AZ protects against a failure that redundant instances in a single zone do not.
• Explain what retry-with-backoff, circuit breaker, bulkhead, and timeout each protect against, and how they work together on a single failing call without stacking into a retry storm.
• Explain what signal drives autoscaling, why a queue can absorb a burst faster than autoscaling can react, and what cache-aside trades away (staleness) for reduced load on a primary data store.
• Explain the difference between a health check consumed by a load balancer and the same check consumed by a monitoring system, and why runtime-tunable configuration belongs outside the deployed artifact.

---

Do it with Claude

Pair, Do and Prove run in Claude Code, with the onboarding-tutor skill. Click a button to copy the exact prompt, then paste it into Claude Code in this repo.

Open the tutor ⧉ Start the gate ⧉

1. Learn · acquire the concept

No external course — read this brief, then go deeper in the four reference pages below.

Mental model (20 minutes):

flowchart TB
    A["Availability<br/>(health checks, load balancing, multi-AZ)<br/>keep the SYSTEM serving traffic"]
    R["Resiliency<br/>(retry, circuit breaker, bulkhead, timeout)<br/>keep one failing CALL from cascading"]
    S["Scalability<br/>(autoscaling, queues, cache-aside)<br/>handle LOAD beyond current capacity"]
    M["Management & monitoring<br/>(health endpoint monitoring, external config)<br/>let operators SEE and CHANGE state"]
    A --> R --> S --> M

• Availability is about surviving failure at the instance and data-center level — the system keeps serving even though a part of it just broke.
• Resiliency is about one call to a dependency, and stopping its failure from spreading to the caller or to other callers of the same dependency.
• Scalability is about demand outpacing current capacity — matching capacity to load, or absorbing a burst faster than capacity can react.
• Management and monitoring patterns are what let operators actually see all of the above happening and change behavior at runtime, without a redeploy.
• None of these patterns make any single component more reliable in isolation — they arrange the system to keep working even though individual parts fail, slow down, or run out of capacity.

Go deeper: Availability patterns · Resiliency patterns · Scalability patterns · Management and monitoring patterns

Check yourself — a team's service has one instance per Availability Zone across three AZs, each behind a load balancer with a real health check. A dependency it calls starts failing intermittently. Which category of pattern is missing from this description, and why does the service still risk an outage?

Resiliency. Availability (multi-AZ, load balancing, health checks) protects against instance/AZ failure, but says nothing about how the service calls its dependency. Without retry-with-backoff, a circuit breaker, and a timeout on that call, the dependency's intermittent failures can still hang or crash the calling service.

Check yourself — why is a health check described in both the Availability and the Management/monitoring pages?

It's the same endpoint serving two different audiences: the load balancer uses it to make routing decisions (availability); a monitoring system scrapes the same endpoint to produce dashboards and alerts for a human operator (management/monitoring). One check, two consumers.

Done when: you can name which category (availability, resiliency, scalability, management/monitoring) a given scenario's gap belongs to, and explain why the four categories don't substitute for each other.

2. Pair · passive → active

Drive the onboarding-tutor:

• "Give me a service with no health check and make me describe exactly what breaks — for the load balancer and separately for a monitoring dashboard."
• "Walk me through a downstream dependency failing intermittently, and make me name which of retry, circuit breaker, bulkhead, or timeout addresses which part of the failure — and where stacking them wrong causes a retry storm."
• "Give me a traffic pattern (steady growth vs. a 30-second spike) and make me pick autoscaling or a queue, and justify why the other one wouldn't react in time."
• "Quiz me on cache-aside versus reading the primary store directly, and make me name what staleness risk I'm accepting."
• "Give me a scenario needing a runtime config change at 3am with no redeploy, and make me name the pattern and its tradeoff."

Common gotchas

• Treating these as Azure-only or AWS-only patterns. Fix: they're technology-agnostic — the same Circuit Breaker or Cache-Aside concept applies on any cloud, and the vocabulary (Well-Architected, Architecture Center) is just where it's best documented, not where it's exclusive to.
• Reaching for every pattern by default. Fix: each pattern trades something (latency, complexity, resource cost, staleness) for the problem it solves — pick based on a real constraint or risk in the workload, not because a pattern exists.
• Confusing availability with resiliency. Fix: availability keeps the system serving traffic through instance/AZ failure; resiliency keeps one call from cascading when a specific dependency is slow or broken. A highly-available system can still cascade-fail on a bad dependency call with no resiliency patterns in place.

Done when: you can pick the right pattern (or combination) for a described failure or load scenario and name the tradeoff it accepts, without notes.

3. Do · produce an artifact

Exercise — a pattern-selection memo:

1. Pick a service you've deployed in an earlier module (e.g. something on module 04 (Kubernetes), or on module 05 (AWS)) as your subject.
2. Write cloud-design-patterns-memo.md naming, for that service: one availability pattern already in place or missing, one resiliency pattern for its riskiest downstream call, one scalability pattern for its traffic profile, and one management/monitoring pattern for how an operator would change its behavior at runtime.
3. For each of the four, state the specific failure or load scenario it addresses — not "best practice."
4. Add a section naming one pattern you deliberately did not add, and why the tradeoff isn't worth it yet for this service.

Done when: cloud-design-patterns-memo.md names one pattern per category with a specific justifying scenario for each, and names one pattern skipped on purpose with its reasoning.

4. Prove · understanding gate

Mandatory. Pass bar in the Socratic gate.

1. Availability: What does a health check actually verify, and why does multi-AZ protect against a failure that multiple instances in one AZ do not?
2. Resiliency: Name the four resiliency patterns and what each specifically protects against. What's a retry storm, and which two patterns together prevent it?
3. Scalability: Why can a queue absorb a burst that autoscaling can't react to in time? What does cache-aside trade away for reduced load on the primary store?
4. Management/monitoring: Why is the same health check described as both an availability and a management/monitoring pattern? What does an external configuration store buy you, and what's its cost?
5. Verification: Which specific claim in your memo did the tutor suggest, and how did you verify it was correct — by checking the Azure Architecture Center or AWS Well-Architected documentation, not by trusting the explanation?

Pass bar: you can defend every pattern in your memo by the specific failure or load scenario it addresses — not just "it's best practice" — and show how you verified a tutor-suggested detail against real documentation. "It works but I can't say why" = back to Pair.

5. Retain · fight forgetting

This module has no generated Anki deck yet. Recall by re-reading the four reference pages and re-running the Do exercise's memo against a different service until you can name all four pattern categories, one pattern from each, and its specific justifying scenario from memory, unprompted. Done when you can do that, cold, for any service someone hands you.

Key takeaways

• Availability patterns (health checks, load balancing, multi-AZ) keep the system serving traffic through instance and data-center failure.
• Resiliency patterns (retry-with-backoff, circuit breaker, bulkhead, timeout) keep one failing dependency from cascading — and must be combined carefully to avoid a retry storm.
• Scalability patterns (autoscaling, queue-based load leveling, cache-aside) handle load beyond current capacity at three different points, each with its own reaction time and tradeoff.
• Management/monitoring patterns (health endpoint monitoring, external configuration store) let operators see system state and change behavior at runtime without a redeploy.
• This is the standard, technology-agnostic vocabulary from the AWS Well-Architected Framework and Azure Architecture Center — it transfers to any cloud, not just the one it's best documented on.

Go deeper — curated resources

Hand-picked external material to take this topic further — the best books, courses, talks, and writing. Cost is tagged Free, Free online (full text/course free on the web), or Paid.

• Docs · Azure Architecture Center — Cloud design patterns — Microsoft. The canonical, technology-agnostic catalog covering every pattern in this module (Circuit Breaker, Bulkhead, Cache-Aside, Queue-Based Load Leveling, Health Endpoint Monitoring, External Configuration Store, and more) with problem statements and tradeoffs. Free.
• Docs · AWS Well-Architected Framework — Amazon Web Services. The six-pillar framework (reliability and performance efficiency cover this module's availability, resiliency, and scalability concerns) for evaluating cloud architecture tradeoffs. Free.

---

Gate log (mentor fills on pass)

• Date passed:
• Passed by: / checked by:
• Weak spots noticed (feeds system improvement):