Retry and Fallback
Reliable workflows expect temporary failure and define what happens next.
Reliable workflows expect temporary failure and define what happens next.
Repeat transient operations with limits.
Use a safer alternate path.
Store failures for later review.
Understand the working model
Not every failure deserves an immediate retry. Rate limits and network timeouts may recover; invalid input usually will not. Classify failures before deciding what to do.
Use bounded retries with increasing delay so a temporary outage does not create a retry storm. After the limit, fall back to a queue or human review.
Practice
Apply the pattern above to one real task you already do. Keep the first version small enough that you can inspect every input and output.
Do not create infinite retries. They hide failures and can amplify cost.
Define retry limits, fallback behavior and a visible place for failed jobs.