Part 27 · Best practices

Timeouts, retries, bulkheads and scheduled work

Prerequisites: 01-ecosystem

When does retry improve reliability?

Overall deadline: finite budget; Concurrency limit: protect dependency; Dependency call: per-attempt timeout; Retry decision: transient + safe?; Final outcome: success or explicit failure. Connections: Overall deadline to Concurrency limit (admit); Concurrency limit to Dependency call (attempt); Dependency call to Retry decision (failure); Retry decision to Concurrency limit (bounded retry); Dependency call to Final outcome (success / exhausted)
Policy sketch, not annotation execution order. Retry and transaction nesting must be chosen deliberately. [S51] [S52] [S53]

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]
Keep this: Resilience protects a budget; it does not promise eventual success.
Check yourself: Is retrying every failure always safer?

No. Permanent failures waste capacity, and non-idempotent operations may repeat side effects.

Sources & further reading

  1. [S51] Framework resilience

    Spring project maintainers · documentation · accessed 2026-10-09 · Documentation retrieved 2026-10-09

    Supports: Framework 7 retry/concurrency limit; EnableResilientMethods

    Read the linked section to validate the mechanism and its version-specific constraints.

  2. [S52] Cloud Circuit Breaker

    Spring project maintainers · documentation · accessed 2026-10-09 · Documentation retrieved 2026-10-09

    Supports: Circuit breaker abstraction

    Read the linked section to validate the mechanism and its version-specific constraints.

  3. [S53] Scheduling and async

    Spring project maintainers · documentation · accessed 2026-10-09 · Documentation retrieved 2026-10-09

    Supports: Executor/scheduler distinction; Async proxy invocation

    Read the linked section to validate the mechanism and its version-specific constraints.