coding-resiliencelisted

# Design for self-healing; never assume an external resource is up ## Overview No external resource is guaranteed. A connection, remote service, API, proxy, DNS name, disk, CPU/memory, mount, or DB pool can be absent, slow, flaky, rate-limited, or vanish mid-run. Never treat one as granted or stable. Build the self-healing in from the start instead of coding the happy path and bolting on error handling later. Resilience lives at the I/O boundary (the adapter), not in the domain - see `bitranox:coding-python-clean-architecture`. ## When to use - Calling a network service, HTTP/REST API, proxy, or DNS name. - Reading/writing a DB, connection pool, mount, or remote filesystem. - Driving a remote host over SSH (`bitranox:compuse-ssh`) or VNC (`bitranox:compuse-vnc`). - Bulk-fetching from a host that throttles per IP (see `bitranox:net-rotating-proxies`). - A heavy step that needs disk / CPU / memory headroom that may not be there. - Any adapter sitting at an I/O boundary. ## Patterns For the modern Python pick behind each, see `bitranox:coding-python-use-modern-libraries`. - **Retry with backoff + jitter, always under a hard timeout.** Retry only transient failures (timeouts, connection resets, 429/503); never retry a deterministic 4xx. Exponential backoff with random jitter avoids a thundering herd. Cap the attempts AND put a timeout on every individual wait and on the whole operation - an unbounded retry with no timeout is a hang, not resilience. Python: `tenacit