# Dependencies and Resilience

For each database, cache, HTTP or RPC service, message system, object store, filesystem, or SDK, record its business role, calls per operation, normal and degraded latency, concurrency or pool quota, payload size, deadline, cancellation, retry, degradation, and complete-outage behavior.

Compute combined amplification when loops, fan-out, and retries overlap.

## Deadline and retry budgets

Start with the caller deadline and allocate queue wait, connection wait, local work, downstream calls, backoff, and response handling.

- A downstream timeout must fit inside the remaining deadline.
- Propagate cancellation and stop work that no longer has a caller or business owner.
- Avoid retries at every layer.
- Do not blindly retry unknown outcomes or irreversible side effects.
- Detached background work needs explicit ownership, persistence, and lifecycle.

A retry policy defines total time, maximum attempts, retryable errors, backoff, jitter, and idempotency. Fail fast, queue, degrade, or open a circuit when recovery cannot fit the deadline or the dependency is overloaded.

## Overload and propagation

Choose bounded concurrency, bounded queues, rate limits, backpressure, fast rejection, circuit breaking, tenant isolation, or a defined degraded result. State what happens at the limit; an unbounded queue turns rejection into delayed timeout and memory pressure.

Walk through slow responses, partial errors, complete outage, successful operation with lost response, pool exhaustion, and traffic return after recovery. Ensure fallbacks and backlog catch-up cannot overload the next dependency.

Cancellation, errors, timeouts, and shutdown must release connections, files, locks, temporary data, timers, and background tasks. Validate leaks under sustained execution, not only one request.