| name | principle-resiliency |
| description | Resiliency principles — fault tolerance, resilience, partial failure, blast radius, failure domains, bulkheads, resource isolation, graceful degradation, fail-fast vs fail-soft, health checks, liveness vs readiness probes, cascading failure, gray failure, fault isolation, idempotency, idempotency keys, safe retry, deduplication, exactly-once, rate limiting, throttling, quotas, backpressure, token bucket, leaky bucket, jitter, thundering herd, synchronized retries, 429. Auto-load when designing for partial failure, isolating dependencies via bulkheads, planning graceful degradation, choosing fail-fast vs fail-soft, configuring health/readiness/liveness probes, evaluating cascading failure risk, designing fallback paths, reviewing system-level fault tolerance, making operations safely retryable with idempotency keys, implementing dedup stores, designing rate limiters or token buckets, handling 429 responses and backpressure, adding jitter to avoid thundering herd retry storms and synchronized retry spikes, or preventing double-execute with idempotency key dedup. |
Resiliency
Distributed systems fail partially, not totally. Resilience is the discipline of staying useful when components, networks, or dependencies degrade.
Failure Domains
A failure domain is the set of components that fail together. Name failure domains before designing for them — unnamed domains produce unnamed blast radii.
- Crash failure — process exits; detectable immediately by the load balancer or orchestrator.
- Slow failure — process responds but takes too long; the most dangerous mode. Threads and connections fill; the caller eventually crashes too.
- Gray/Byzantine failure — process returns wrong data or errors intermittently; hardest to detect.
- Partial failure — some instances or shards fail while others serve normally.
Cascading failure: a degraded dependency holds resources long enough that the caller exhausts its own pools, propagating failure upstream. Root cause is almost always unbounded resource sharing across failure domains.
Bulkheads
Named after ship compartments: isolate resource pools so a breach in one dependency does not exhaust resources for all others.
- Allocate a separate bounded connection pool, semaphore, or thread pool per downstream dependency.
- Never share a single pool across unrelated dependencies — a slow third-party API must not starve database connections.
- In multi-tenant systems, partition queues or workers per tenant to contain noisy-neighbor starvation.
- Size each bulkhead to the dependency's realistic concurrency ceiling, not the caller's maximum.
Fail-Fast vs Fail-Soft
Fail-fast — surface the error immediately without attempting recovery.
Use when: an invariant is violated, the operation cannot be retried safely, or the system state is unrecoverable.
Examples: config missing at startup, corrupted schema, required auth service unreachable at boot.
Fail-soft — continue serving a degraded response using a fallback, stale cache, or reduced feature set.
Use when: the failed component is non-critical and a safe, non-misleading fallback exists.
Examples: recommendation service down → return empty list; search unavailable → hide the search bar.
Never fail-soft when the degraded response is actively misleading or could corrupt downstream state.
Survive Faults at I/O Boundaries
Every I/O call must have a deadline. Call-site mechanics (timeouts, retry with backoff, circuit breakers) are covered in principle-error-handling#Timeouts and Deadlines, principle-error-handling#Retries and Backoff, and principle-error-handling#Circuit Breakers. System-level constraints:
- Retries are only safe on idempotent operations — see
principle-api-design#Idempotency. A non-idempotent retry corrupts state; the retry budget does not excuse skipping idempotency design.
- Circuit breakers and bulkheads are complementary: deploy both for full dependency isolation.
Graceful Degradation
Define degraded modes before incidents require them. "We'll figure it out" is not a fallback strategy.
- Fallback ladder (cheapest to most expensive to maintain): in-process cache → stale read replica → CDN-cached response → feature-toggle off → friendly error page.
- Shed expensive paths first: drop personalization, search, or aggregations before dropping core reads.
- Read-only mode is a valid degraded state for write-heavy systems when the write path fails.
- Feature toggles allow disabling non-critical paths without a deploy.
Health Checks
Liveness — is the process alive? A failed liveness probe triggers container restart. Only fail liveness on truly unrecoverable conditions (deadlock, corrupted runtime state). Failing liveness during a dependency outage causes restart storms.
Readiness — is the process ready to serve traffic? A failed readiness probe removes the instance from rotation without restarting. Fail readiness when a required upstream is unavailable.
Startup — is the process still initializing? Prevents liveness from killing a slow-booting instance (cache warm, schema migration).
Shallow check: port open, fast HTTP 200. Always-on.
Deep check: validates dependency connectivity. Readiness only — never liveness.
Cascading-check trap: if every instance polls every dependency on each health interval, a slow dependency produces a check storm that looks like total outage.
For SLI/SLO framing of availability signals, see principle-observability#SLI / SLO / Error Budget.
Idempotency
An operation is idempotent if executing it multiple times produces the same outcome as executing it once. Idempotency is the precondition for safe retry.
- Idempotency key — a stable, client-generated ID that uniquely identifies a logical request. The server stores the key; on duplicate submission it returns the stored result instead of re-executing.
- Safe HTTP methods — GET, PUT, and DELETE are idempotent by spec. POST is not; add an
Idempotency-Key request header to make individual POST calls safely retryable.
- At-least-once vs exactly-once — networks guarantee at-least-once delivery at best. Exactly-once semantics = at-least-once delivery + idempotent or dedup processing. There is no true exactly-once over an unreliable network without a dedup layer.
- Dedup store states — track each key as
pending (in-flight) or completed (result stored). A retry arriving while the original is still pending must wait or return a conflict — never execute a second time.
- Ordering trap — reserve the idempotency key (insert
pending) before executing the side effect, not after. Executing first leaves a window where a concurrent retry sees no record and proceeds, causing a double-execute.
For the API contract perspective see principle-api-design#Idempotency. For distributed delivery semantics see principle-distributed-systems#Idempotency Across the Network.
See examples/ for a worked idempotency-key dedup store — prevents double-charge on concurrent retries (read on demand — not auto-loaded).
Rate Limiting
Rate limiting controls request volume to protect producers from overload and consumers from accidental burst.
- Token bucket — bucket holds up to N tokens; each request consumes one; tokens refill at a steady rate. Allows short bursts up to bucket capacity, then enforces the steady-state rate.
- Leaky bucket — requests enter a queue and drain at a fixed rate regardless of burst, producing constant-rate output at the cost of higher latency.
- Fixed/sliding window — simpler to implement; fixed window has a boundary-burst caveat: a client can send up to 2× the limit across a window boundary. Sliding window tracks per-slot request counts and avoids this burst by weighting across the boundary — at the cost of more state per client.
- Quota headers — servers should return
RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, and Retry-After. Clients must honor Retry-After; ignoring it escalates to a ban.
- Client-side backpressure — use bounded queues that reject new work when full rather than growing unboundedly. A 429 means slow down now, not retry immediately.
- Jitter on retry — when many clients hit a rate limit simultaneously, synchronized retries produce a thundering herd at the next interval. Add random jitter; see
principle-error-handling#Retries and Backoff.
See examples/ for a worked token-bucket rate limiter — enforces steady rate, allows controlled bursts, rejects with jitter (read on demand — not auto-loaded).
When Resiliency Engineering is Overkill
- Single-process tools with no network dependencies; crash-and-restart is the recovery.
- Batch jobs where idempotent restart is sufficient failure handling.
- Prototypes with one developer and no production traffic.
- Internal tools where one team owns both ends of every dependency.
Red Flags
| Flag | Problem |
|---|
| Single connection pool shared across all dependencies | Slow dependency exhausts connections for every other caller |
| Retry without idempotency | Non-idempotent retries corrupt state; budget wasted |
| Liveness probe that calls a downstream service | Dependency outage triggers container restart storm |
| Deep health check on every load-balancer poll interval | Health-check storm makes partial outage appear total |
| No explicit degraded mode for non-critical paths | Fallback invented under incident pressure |
| Fail-soft returning a misleading or stale result | User confusion or downstream data corruption |
| No per-dependency resource isolation | Any slow caller can exhaust all threads or connections |
| Idempotency key recorded after the side effect | Concurrent retry sees no record → executes the operation a second time |
| Treating exactly-once as achievable without a dedup layer | At-least-once delivery + no dedup = duplicate side effects under retries |
| Rate-limit retry without jitter | Synchronized retries → thundering herd; load spike repeats every retry interval |
| Unbounded client queue under backpressure | Memory grows without limit; OOM instead of graceful rejection |
Ignoring Retry-After header | Client hammers server immediately; risks escalation from throttle to ban |
