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 1Calculate 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 2Replace 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 3Choose 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 connectionResilience 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
TOOL 1./ops/setup-sre-local-lab.sh
TOOL 2for i in $(seq 1 10); do curl -s -o /dev/null http://127.0.0.1:8000/fail || true; done
TOOL 3curl -fsS http://127.0.0.1:9090/api/v1/query --get --data-urlencode 'query=sre_demo:error_ratio:1m'
TOOL 4for 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.