SRE / Reliability Engineering Fundamentals · Module 10 of 12

Resilience, safe change and recovery

Design systems and delivery practices that contain failure: timeouts, bounded retries, isolation, graceful degradation, canaries, rollback and recovery objectives tied to tested evidence.

Running case · checkout service

Carry the same user journey forward: customer → edge/API → checkout → payment. Reuse prior SLI/SLO, alert, incident and recovery decisions where relevant so this module adds evidence to one reliability system rather than starting from zero.

Learning objectives

By the end of this module, you should be able to:

  • Explain how timeouts, retry budgets and isolation prevent cascading failure.
  • Use canary and rollback evidence to reduce change risk.
  • Distinguish service restoration from longer-term disaster recovery and data-recovery objectives.

Bound failure propagation

Timeouts stop requests from waiting forever; retries can recover transient failures but must be bounded, delayed and budgeted; bulkheads or isolation prevent one workload from consuming every shared resource.

Define attempts versus retries precisely. Three total attempts at each of three layers can create 27 backend attempts; three retries means four attempts at each layer and can create 64. Prefer retrying at one appropriate layer, with deadlines, backoff, jitter and a retry budget.

Graceful degradation preserves the core journey

When a noncritical dependency fails, a service can disable recommendations, serve cached data or reduce expensive features while keeping the critical transaction available.

Document what can degrade and what must fail closed for correctness, security or compliance.

Safe change needs independent evidence

Canaries, staged rollout and automated rollback reduce blast radius when release health is evaluated with user-facing signals. A deployment system saying “success” does not prove the service is healthy.

Recovery objectives should distinguish the recovery time objective (RTO)—how quickly service must return—from the recovery point objective (RPO)—how much data loss is acceptable, then validate both with exercises rather than assuming backups or failover will meet them.

Circuit breakers and idempotency constrain repeated failure

A circuit breaker temporarily stops calls to a dependency that is predictably failing, then probes recovery instead of continuing to spend resources on work likely to fail. It is a containment mechanism, not a substitute for capacity or dependency repair.

For side-effecting operations such as payments, retries require idempotency. An idempotency key or equivalent transaction contract lets a repeated request return the original outcome rather than charging the customer twice.

Worked example

Attempts versus retries

3 TOTAL ATTEMPTS per layer × 3 layers = 3³ = 27 backend attempts
3 RETRIES per layer means 4 attempts × 3 layers = 4³ = 64 backend attempts
  • Retry terminology must state total attempts or additional retries.
  • Layered retries can amplify overload; keep retry responsibility at one layer when practical and enforce a retry budget.
Core lab · account-free

Lab 10 — Model retry amplification and graceful degradation

Goal: Calculate retry amplification and design a bounded recovery policy.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
  • Running case study: use the same checkout journey throughout the course unless the lab explicitly says otherwise.
STEP 1

Calculate layered retries

python3 - <<'PY2'
layers=3
for retries in (2,3):
    attempts=1+retries
    print(f'{retries}_retries_per_layer => {attempts}^{layers} = {attempts**layers} backend attempts')
print('three_total_attempts_per_layer =>',3**layers)
PY2
STEP 2

Replace with a bounded policy

Design one retry layer with: total-attempt limit, end-to-end deadline, exponential backoff + jitter, a retry budget, retriable/non-retriable status policy and a circuit-breaker open/half-open rule.

STEP 3

Choose a degradation rule

For checkout/payment, define an idempotency-key rule and one graceful-degradation choice. Then set an RTO and RPO for a regional failure and state the game-day test that would prove them.

Verify

  • The learner distinguishes retries from attempts and recognizes both 27- and 64-attempt interpretations.
  • The design includes one retry owner, budget/deadline/backoff, idempotency for payment side effects, a degradation choice and testable RTO/RPO.

Expected outcome

  • A bounded retry/circuit-breaker policy, idempotent payment contract, graceful-degradation rule and a disaster-recovery exercise with measurable RTO/RPO.

Diagnose / troubleshoot

  • If every layer retries, consolidate retry responsibility.
  • If fallback data can be unsafe or stale, define freshness/correctness limits before enabling it.
Real-world connection

Resilience is the ability to contain failure and restore the user journey with predictable trade-offs.

Real-tool practicum · optional but recommended

Optional practicum — verify failure and recovery against SLI evidence

Generate failures, recover with healthy traffic and compare the Prometheus error signal before/after.

Prerequisites

  • Docker/Compose available.
  • SRE Lab Pack or release source tree.

Resources created

  • Local demo failure/recovery evidence.

Cost / risk

  • Local CPU/RAM only.
TOOL 1
./ops/setup-sre-local-lab.sh
TOOL 2
for i in $(seq 1 10); do curl -s -o /dev/null http://127.0.0.1:8000/fail || true; done
TOOL 3
curl -fsS http://127.0.0.1:9090/api/v1/query --get --data-urlencode 'query=sre_demo:error_ratio:1m'
TOOL 4
for i in $(seq 1 40); do curl -s -o /dev/null http://127.0.0.1:8000/ok; done

Verify

  • The service-level error signal reflects both failure injection and subsequent recovery.

Cleanup

  • ./ops/cleanup-sre-local-lab.sh

Warnings

  • Never test retry storms, circuit breakers or destructive failover on production without an approved game-day plan.
  • Recovery is not proven until the affected user SLI and data-integrity criteria recover.
Avoid these traps

Common mistakes

  • Retrying indefinitely without a deadline.
  • Calling a rollout successful based only on deployment-controller state.
  • Using graceful degradation for data where stale or partial results are unsafe.
Knowledge check

Can you connect the reliability objective to an engineering decision?

Three concept checks plus one scenario check.

1Why must retries be bounded?

Unbounded or layered retries can amplify load, extend latency and worsen an overloaded dependency.

2What is graceful degradation?

Preserving the critical user journey by reducing or disabling nonessential capability when dependencies or capacity are impaired.

3What should determine canary promotion?

Independent service/user health evidence and explicit rollback criteria, not deployment completion alone.

4Scenario: a new release is deployed successfully but checkout SLI drops below objective. What is the correct reliability decision?

Treat the change as unhealthy and follow the rollback/mitigation policy even though the deployment system reports success.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.