Topic 11.9 + 11.10 — Retry, Timeout
In one line
Timeouts bound how long a call may take; retries give it another chance — together they form the reliability primitive.
Think of it like this
Calling a friend who doesn't answer: you hang up after a reasonable time (timeout) instead of holding forever, and you try again a little later (retry) instead of assuming they're gone forever.
Key ideas
- 01
Timeout: always set one — a call without a timeout is an infinite thread pod (the classic 30s default horror).
- 02
Total timeout discipline: your SLA > sum of nested timeouts; set per-hop + overall budgets.
- 03
Retry with backoff+jitter on transient failures (5xx, network); no retry on 4xx (client errors won't heal).
- 04
Retry budget per request: cap attempts and total time; too many retries = load amplification storms.
- 05
Retry + breaker: retry a couple times, THEN let the breaker open — they sequence, they don't compete.
- 06
Interview: '2s timeout per hop, 2 retries with jitter, breaker opens after the 3rd aggregate failure'.
Java / Spring map
- →
Spring: @Retryable(maxAttempts=3, backoff=@Backoff(delay=100,multiplier=2,jitter=50)); HTTP client read timeout.
Explain without notes
Why is retrying a 404 pointless and retrying a 503 smart? And when is even a 503 worth NOT retrying (breaker already open)?
Practice
Write the retry classification table (transient/permanent) for your APIs.
Trade-offs
- ↔
Retries buy resilience at the price of load; every retry policy must include a cap and share the breaker.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
Every call I design has an explicit timeout, a classified retry, and a breaker above it.