Timeouts, retries, bulkheads and scheduled work
Prerequisites: 01-ecosystem
When does retry improve reliability?
Goal & mental model verified
Framework 7 has core retry and concurrency-limit facilities with explicit enabling. Circuit breakers address repeated dependency failure. Executors run tasks; schedulers decide when to trigger them. @Async commonly relies on proxy invocation.
[S51] [S52]Worked example · design exercise synthesis
An insurer times out after receiving a quote request. Retry only under an idempotency contract; otherwise a successful but lost response can lead to duplicate work.
[S51] [S52] [S53]Engineering decision synthesis
Set an overall deadline, per-attempt budgets and bounded concurrency. Retry selected transient failures with backoff/jitter; a fallback must preserve honest business semantics.
[S51] [S52] [S53]Pitfall & diagnosis synthesis
Retries amplify overload. The new Framework retry API and older Spring Retry have different packages/settings. Scheduled work can run on every replica unless coordination is explicitly designed.
[S51] [S52] [S53]Improve & validate synthesis
Inject latency, partial failure and response loss. Measure total attempts and deadline breaches; verify limits protect dependencies and that failed work has an observable final outcome.
[S51] [S52] [S53]Check yourself: Is retrying every failure always safer?
No. Permanent failures waste capacity, and non-idempotent operations may repeat side effects.