Worked case · Failure and stress · 12 figures

Retry and overload control

Control retries and overload

Figure 01 / 12

Dependencies form a critical path

Dependencies form a critical path — Retry and overload control. Illustrative service dependency graph. Exact values are in the figure data below.
Illustrative service dependency graph

The case examines control retries and overload. Each edge is a required handoff in this illustrative path. A service can respond quickly while a downstream effect remains incomplete, so health needs both technical and business evidence.

Figure data and text version
FromToHandoff
Retry and overload controlDecision serviceAction request
Decision serviceEvidence providerRequired evidence
Decision serviceState storeDurable decision
State storeEffect publisherPending effect
Effect publisherExternal railFinancial action

A retry consumes capacity even if it produces no new business value. Independent retry policies at several layers can multiply load during a partial failure.

Clients, gateways, and workers retry the same unknown action at once.

All amounts, rates, capacity limits, and outcomes in this case are synthetic. The three conditions are separate assumptions for comparison. A better result in the response condition is not measured proof that the proposed control causes that improvement. The figures expose the calculation and its limits; a real deployment needs its own evidence.

Read the result

950 intended requests generate 1710 processing attempts under this retry assumption. Capacity is 632 attempts per interval, and the critical path consumes 305 ms of a 240 ms budget. The request-based SLO view observes 3000 bad requests against an illustrative allowance of 100. These measurements must be connected to the financial effect and control evidence before declaring recovery.

Model inputs and calculated values

Inputs below are the case-specific values. Each figure states the condition-specific assumptions and units used in its calculation. Calculated values are rounded for display.

InputValue
arrivals950
capacity1,150
budgetMs240
Calculated valueResult
arrivals950
attempts1,710
capacity632
latency305
budget240
remaining-65
window100,000
bad3,000
allowed100
Figure 02 / 12

Allocate the latency budget explicitly

Allocate the latency budget explicitly — Retry and overload control. Milliseconds on one critical path. Exact values are in the figure data below.
Milliseconds on one critical path

The four stages total 305 ms against a 240 ms budget, leaving -65 ms. Negative remaining time means this modeled path exceeds the target before adding any unmodeled overhead. The values are fixed teaching observations, not a latency guarantee.

Figure data and text version
StageMilliseconds
Ingress25
Feature reads55
Control evaluation180
Commit and response45
Remaining budget-65
Figure 03 / 12

A slow minority changes the tail

A slow minority changes the tail — Retry and overload control. Milliseconds; explicitly constructed percentile profile. Exact values are in the figure data below.
Milliseconds; explicitly constructed percentile profile

The constructed distribution separates the median from high percentiles. Percentiles are order statistics over the same request population; summing stage p99 values is not generally the service p99. This chart is a teaching profile, not a measured production distribution. Horizontal positions are the labeled observations or scenarios; equal spacing does not imply equal numerical increments.

Figure data and text version
PercentileLatency ms
p50214
p75274
p90336
p95427
p99702
Figure 04 / 12

Retries increase attempted work

Retries increase attempted work — Retry and overload control. Attempts per interval. Exact values are in the figure data below.
Attempts per interval

950 original requests produce 1710 attempts under the stated average retry multiplier. The additional 760 attempts consume capacity even when their financial effect must remain idempotent. This simple model omits recursive retry storms across multiple layers.

Figure data and text version
Attempt typeCount
Original requests950
Additional attempts760
Figure 05 / 12

Attempted demand versus capacity

Attempted demand versus capacity — Retry and overload control. Attempts; measures are not all additive. Exact values are in the figure data below.
Attempts; measures are not all additive

The interval has capacity for 632 attempts against 1710 attempted requests. The difference is 1078 unserved attempts in this simplified window. An unserved attempt is not necessarily an unexecuted business action: reconcile the stable action identifier before retrying a financial effect.

Figure data and text version
MeasureAttempts
Attempted demand1,710
Processing capacity632
Served this interval632
Unserved this interval1,078
Figure 06 / 12

Overload leaves a durable backlog

Overload leaves a durable backlog — Retry and overload control. Attempts waiting at interval end. Exact values are in the figure data below.
Attempts waiting at interval end

The six intervals use explicitly varied arrival multipliers and constant capacity. The queue carries forward unfinished attempts. Real systems also need a maximum age, admission policy, and expiry semantics so delayed work does not execute after its business authority has ended. Horizontal positions are the labeled observations or scenarios; equal spacing does not imply equal numerical increments.

Figure data and text version
IntervalPending attempts
T1565
T21,472
T33,063
T45,338
T56,758
T67,494
Figure 07 / 12

Throughput can stay flat while demand rises

Throughput can stay flat while demand rises — Retry and overload control. Attempts per interval. Exact values are in the figure data below.
Attempts per interval

The completion count is limited by available work and capacity. A saturated completion line with a growing queue is evidence of overload, not stable end-to-end service. Inspect waiting time and customer outcomes alongside throughput. Horizontal positions are the labeled observations or scenarios; equal spacing does not imply equal numerical increments.

Figure data and text version
IntervalAttemptsCompletions
T11,197632
T21,539632
T32,223632
T42,907632
T52,052632
T61,368632
Figure 08 / 12

Write state and pending effect together

Write state and pending effect together — Retry and overload control. Illustrative reliable handoff. Exact values are in the figure data below.
Illustrative reliable handoff

This sequence describes a transactional outbox within one datastore boundary. The publisher can deliver more than once, so the consumer also needs duplicate handling. A durable local handoff does not create a universal exactly-once guarantee across an external payment system.

Figure data and text version
EventCommit boundaryEvidence
Validate actionBefore transactionStable action key and permitted operation
Write state and outboxOne local transactionBoth records commit or neither does
Publish effectAfter commitDelivery may be retried
Consume effectConsumer boundaryIdempotent handling and stored result
ReconcileIndependent checkExpected and observed effects agree
Figure 09 / 12

Repeated delivery and financial effects differ

Repeated delivery and financial effects differ — Retry and overload control. Counts at different boundaries. Exact values are in the figure data below.
Counts at different boundaries

The example contains 1710 transport attempts for 950 intended business actions. The protected effect count cannot be inferred from transport success alone. The table states the intended contract and the evidence needed to check it.

Figure data and text version
MeasureIllustrative valueRequired evidence
Business actions950Stable unique action identifiers
Transport attempts1,710Delivery identifiers and retries
Permitted effects950One effect per authorized action
Observed effectsMust reconcileAuthoritative ledger or external record
Figure 10 / 12

An SLO budget is a measured allowance

An SLO budget is a measured allowance — Retry and overload control. Request-based illustrative SLO; one measurement window. Exact values are in the figure data below.
Request-based illustrative SLO; one measurement window

For 100,000 eligible requests and a 99.9% illustrative SLO, the budget is 100 bad requests. This case observes 3000. Eligibility, success, and measurement windows must be fixed before interpreting the result. An SLO allowance never overrides a legal or financial correctness requirement.

Figure data and text version
MeasureRequests
Eligible population100,000
Bad requests allowed100
Bad requests observed3,000
Remaining budget-2,900
Figure 11 / 12

Dependency failures require scoped behavior

Dependency failures require scoped behavior — Retry and overload control. Dependency-specific policy boundary. Exact values are in the figure data below.
Dependency-specific policy boundary

The dependency is payment gateway. The response depends on the operation, required control, and evidence available. The table gives illustrative behavior classes, not a universal fail-open rule.

Figure data and text version
Failure stateIllustrative responseEvidence to retain
Optional signal lateUse approved degraded policyMissing signal and selected policy version
Required control unavailableHold the affected actionPending owner and expiry
Unknown external outcomeQuery and reconcileOriginal external action identifier
Publisher retryRepeat delivery safelyStable business key and attempt history
Figure 12 / 12

Recovery ends with a reconciled population

Recovery ends with a reconciled population — Retry and overload control. Business recovery sequence. Exact values are in the figure data below.
Business recovery sequence

The last successful health probe does not close the incident. Recovery must classify affected actions, resolve unknown outcomes, restore required controls, and verify money and records. A replay is allowed only under the action’s current authority and idempotency contract.

Figure data and text version
StageCompletion evidence
ContainClients, gateways, and workers retry the same unknown action at once.
ClassifyKnown success, known failure, unknown outcome
ResolveRepair or replay by stable action identifier
VerifyCounts, amounts, and control evidence reconcile
CloseOwners accept remaining exceptions explicitly

Connect the result to the system

Bound retries, use stable action identifiers, and apply admission and backoff policies.

Check the population, evidence, permitted action, and actual effect together. A balanced calculation can still use the wrong population; a successful response can still leave an unknown financial outcome. The case’s numerical result applies only to its stated assumptions.

Sources and further reading

The chapter sources support the concepts and scope. They do not prescribe the synthetic model rates.

  1. Google SRE: handling overload
  2. NIST: Cybersecurity Framework
  3. PostgreSQL: transaction isolation