Find the question you need
Choose a route or begin at Chapter 1. Teaching chapters stay open; the chapter index expands by section.
Define the objects
Chapters 1–2. Keep a job identity across its attempts
Build the argument
Chapters 3–5. Derive the expected attempt count
Compare and interpret
Chapters 6–8. Calculate the offered service load
Check and practise
Chapters 9–10. Handle timeouts and duplicate effects carefully
Questions and next routes
Chapters 11–12. Questions readers ask
Full chapter index · Worked practice · Queueing Theory subject root
Thirty new jobs per hour can generate more than fifty service attempts per hour. A retry does not create a new customer need, but it can consume another unit of service capacity. Measuring only new arrivals hides that extra work.
This guide derives a capped-retry model from the attempts made by one job, then connects it to aggregate load. It distinguishes successful jobs, failed attempts and jobs that exhaust their allowance. All numerical rates are constructed teaching examples.
Chapter index
Define the objects · Chapters 1–2
1. Keep a job identity across its attempts
2. Define the independent failure model
Build the argument · Chapters 3–5
3. Derive the expected attempt count
4. Separate job success from attempt failure
5. Convert the per-job counts into rates
Compare and interpret · Chapters 6–8
6. Calculate the offered service load
7. Compare two, three and four attempts
8. Explain what backoff does and does not change
Check and practise · Chapters 9–10
9. Handle timeouts and duplicate effects carefully
10. Practise with a lower failure probability
Questions and next routes · Chapters 11–12
11. Questions readers ask
12. Sources and connected learning routes
A job is one original task. An attempt is one submission of that task to the service. Let λ₀ be the long-run arrival rate of new jobs. A job may produce several attempts before success or abandonment.
Assign a stable job identifier and a separate attempt number. Without both fields, three records could mean three different jobs or one job tried three times. A queue length measured in attempts cannot be interpreted as a count of distinct unresolved needs without reconciling these identities.
For this model, each attempt uses the same service time s whether it succeeds or fails. Failure is resolved before another attempt of the same job begins. There are no simultaneous duplicate attempts. These assumptions deliberately exclude speculative parallel retries and variable failure costs.
Each attempt independently fails with probability p, where 0 ≤ p < 1. A failed attempt is retried until success or until a maximum of m total attempts has been used. The initial attempt is included in m; a limit of three attempts permits at most two retries.
Let A be the number of attempts made by one original job. A is at least one and at most m. Attempt k occurs only when the preceding k − 1 attempts all failed, so P(A ≥ k) = pᵏ⁻¹ for k = 1,…,m.
The failure probability is a supplied model parameter. It does not increase with queueing delay or load here. That simplification is useful for accounting, but can fail precisely when an overloaded system is being investigated.
For a positive integer-valued variable bounded by m, E[A] = Σₖ₌₁ᵐP(A ≥ k). To see why, a job with A = a contributes one to the first a indicators and zero to the rest. Their sum is a.
Substituting the retry probabilities gives E[A] = 1 + p + p² + … + pᵐ⁻¹ = (1 − pᵐ)/(1 − p). This is an expectation over original jobs, not over attempt records.
With p = 0.5 and m = 3, E[A] = 1 + 0.5 + 0.25 = 1.75 attempts per job. Some jobs stop after one attempt; the value 1.75 does not describe a fractional attempt made by an individual job.
A job exhausts the allowance only when all m attempts fail. Its terminal failure probability is pᵐ, and its probability of eventual success within the allowance is 1 − pᵐ.
The expected number of successful attempts per job is also 1 − pᵐ because this model stops at the first success. The expected failed-attempt count is E[A] − (1 − pᵐ), which simplifies to pE[A].
At p = 0.5 and m = 3, success probability is 0.875, terminal failure probability is 0.125 and expected failed attempts are 0.875 per job. A failed attempt and an ultimately failed job are different outcomes. Counting every failed attempt as a permanently lost job would substantially overstate loss.
Suppose new jobs arrive at λ₀ = 30 per hour. In a long-run regime where the finite per-job work is accounted for and unfinished boundary work is negligible relative to the observation duration, attempt rate is λₐ = λ₀E[A].
For the three-attempt case, λₐ = 52.5 attempts per hour. Successful jobs leave at 30×0.875 = 26.25 per hour. Terminally failed jobs leave at 30×0.125 = 3.75 per hour. These two job outcomes sum to 30.
Failed attempts occur at 30×0.875 = 26.25 per hour. Successful attempts plus failed attempts sum to 52.5. The two reconciliations use different units. They cannot be combined into one departures count without explaining what departs.
| Ledger | Rate per hour | Unit |
|---|---|---|
| Original arrivals | 30 | jobs |
| Successful outcomes | 26.25 | jobs |
| Terminal failures | 3.75 | jobs |
| All attempts | 52.5 | attempts |
| Successful attempts | 26.25 | attempts |
| Failed attempts | 26.25 | attempts |
Let every attempt take one minute of server time. The server can perform sixty such attempts per hour if continuously available. The three-attempt policy offers 52.5 minutes of service work per hour, giving ρ = 52.5/60 = 0.875.
Measuring only new-job input would suggest ρ = 30/60 = 0.5. That calculation misses the service consumed by retries. When evaluating stability, count all work that reaches the resource under study.
A load below one is necessary for ordinary lossless single-server stability and finite spare capacity in this setting; it is not a complete performance guarantee for arbitrary arrival dependence or scheduling. This load calculation alone supplies neither mean waiting time nor a tail-delay bound.
Holding p = 0.5 and new arrivals at thirty per hour, two attempts give E[A] = 1.5, an attempt rate of 45 per hour and a success probability of 0.75. Three attempts give 52.5 per hour and success probability 0.875.
Four attempts give E[A] = 1.875, an attempt rate of 56.25 per hour and success probability 0.9375. The extra permitted attempt improves success in this fixed-p model while using more of the remaining service capacity.
These are not policy recommendations. In a real overloaded service, the extra load may change failure probabilities and response times. A comparison that holds p fixed cannot establish which retry limit performs best after those feedback effects occur.
| Maximum total attempts | E[A] | Attempts/hour | Success probability | Load at one minute/attempt |
|---|---|---|---|---|
| 2 | 1.5 | 45 | 0.75 | 0.75 |
| 3 | 1.75 | 52.5 | 0.875 | 0.875 |
| 4 | 1.875 | 56.25 | 0.9375 | 0.9375 |
CHAPTER 8 OF 12 · Compare and interpret
8. Explain what backoff does and does not change
A delay between retries changes when the work returns. Under the same independent outcomes, no cancellation and eventual execution of permitted attempts, it does not change E[A] or the total service work associated with a job.
Backoff can spread attempts through time; random jitter can reduce coordinated bursts. Neither mechanism creates server capacity. Deadlines, cancellations or a retry budget can reduce actual attempt counts, but then the model must include those stopping rules.
There may also be an orbit of jobs waiting to retry outside the visible service queue. If the question concerns end-to-end time, include that orbit and the backoff intervals in the system boundary. Moving work outside a queue counter does not make its delay disappear.
CHAPTER 9 OF 12 · Check and practise
9. Handle timeouts and duplicate effects carefully
A timeout means the caller did not receive the expected result in time. It does not necessarily mean the server performed no operation. Retrying a completed but unacknowledged operation can repeat a side effect unless the operation has suitable idempotency or deduplication behaviour.
Distinguish transport attempts, actual executions and unique successful outcomes. An idempotent response can protect a business effect while still consuming CPU, network or lookup work on repeated calls. Deduplication therefore changes some workload components without necessarily making every repeat free.
The linked engineering sources discuss these design issues. The arithmetic above assumes a much simpler outcome: each attempt is classified as success or failure and a success stops the job. Do not substitute it for a model of ambiguous execution.
CHAPTER 10 OF 12 · Check and practise
10. Practise with a lower failure probability
Take λ₀ = 40 new jobs per hour, p = 0.2 and m = 3. First calculate attempts per job: 1 + 0.2 + 0.04 = 1.24. The offered attempt rate is 49.6 per hour.
Success probability is 1 − 0.2³ = 0.992. The successful-job rate is 39.68 per hour and terminal failure rate is 0.32 per hour. Expected failed attempts per job are 0.2×1.24 = 0.248, giving 9.92 failed attempts per hour.
Check both ledgers: 39.68 + 0.32 = 40 jobs, while 39.68 + 9.92 = 49.6 attempts. If attempts take one minute, ρ is about 0.8267. State the time unit before using that load.
Does a successful retry remove its earlier failed attempt from workload? No. The earlier attempt already used the resource included in this model. Success changes the job outcome, not the historical work.
Can I assume retry arrivals are Poisson? Not from these calculations. They depend on earlier failures and retry timing. Aggregate rate accounting does not establish an arrival distribution.
What happens with unlimited retries? E[A] becomes 1/(1 − p) when p < 1. With thirty new jobs per hour and p = 0.5, that is sixty attempts per hour, exactly the one-minute server’s capacity. A finite stationary mean wait is not justified at this critical boundary.
Can failures depend on attempt number? Yes. Replace pᵏ⁻¹ with the actual probability that a job reaches attempt k. The tail-sum counting method survives; the geometric shortcut may not.
CHAPTER 12 OF 12 · Questions and next routes
12. Sources and connected learning routes
The engineering references explain why retries can add load and why repeated operations need suitable idempotency. The capped geometric model, ledger identities and worked rates are derived explicitly here under independent fixed-probability outcomes.
Read the whole-batch rejection guide for another case where attempt-level or event-level percentages differ from job outcomes. Follow the system-boundary guide when retries wait outside the queue being measured, and return to Queueing Theory for arrival and service assumptions.
For transfer, ask a learner to rebuild these two ledgers for resubmitted tasks: which entries are new needs, which are repeated work, and which outcomes close a need? Keep the identity, unit and boundary visible before applying a queue formula.
References checked 22 October 2026
Amazon Builders’ Library: timeouts, retries and backoff with jitter
Amazon Builders’ Library: making retries safe with idempotent APIs
Continue through Queueing Theory
Whole-batch rejection and event versus job loss rates
Little’s Law and the waiting-room boundary
Queueing Theory root and full subject directory · The Gold Standard of Education · How X Works