Retry Strategy Simulation

SIMULATED RESULT

Outcomes by retry strategy

What this simulation found

In this constructed scenario, full jitter was the only strategy whose median trial completed all 500 clients within the retry limit. It used 1,956 total attempts and reached a median 95th-percentile success time of 2.686 seconds. Immediate retry completed 25 clients, while fixed delay and exponential backoff without jitter each completed 225 because their retry waves stayed synchronized.

Median trial value across 100 trials per strategy
Strategy	Successful clients	Final failures	Total attempts	Peak retries per window	Retry collisions	P95 success time
Immediate retryRetry after 1 millisecond, effectively remaining in the same service window.	25 / 500	475	4,300	3,800	3,800	0 ms
Fixed delayRetry every 500 milliseconds.	225 / 500	275	3,600	475	2,900	4.000 s
Exponential backoffStart at 250 milliseconds, double each retry, and cap at 4000 milliseconds.	225 / 500	275	3,600	475	2,900	19.750 s
Exponential backoff with full jitterChoose a seeded delay from 0 through the current exponential cap, with a 1 millisecond simulation minimum.	500 / 500	0	1,956	248	981	2.686 s

A retry collision is a retry that reached a 100 millisecond service window after its 25-request capacity was exhausted. Success-time metrics include successful clients only.

Fixed simulation scenario

Five hundred clients make an initial request at simulated time zero. The service accepts 25 requests in each aligned 100 millisecond window. A rejected client may retry eight times under the selected schedule.

Clients: 500 at time zero
Service capacity: 25 requests per 100 ms
Retry limit: 8 retries per client
Base delay: 250 ms
Fixed delay: 500 ms
Backoff cap: 4,000 ms

Scenario SHA-256: a0137b33867fdb68dc3e35b6dd5ea144b0e405c05761379b88d6dd0d5c089fa6

Methodology

Measure how synchronized and randomized retry schedules change successful completion, failed attempts, retry collisions, and simulated completion time in one fixed-window contention scenario.

Trials: 100 per strategy
Statistic: Median trial metric, with minimum and maximum retained
Event order: Ascending simulated millisecond, then insertion sequence
Service model: Fixed aligned windows with independent capacity in each window
Collision definition: A retry arriving after capacity is exhausted in its service window

1
Create 500 client events at simulated time zero and order equal-time events by insertion sequence.
2
Accept the first 25 arrivals in each aligned 100 millisecond service window and reject later arrivals in that window.
3
For each rejection, schedule the next attempt according to the selected policy until the client succeeds or uses eight retries.
4
Repeat each strategy with seeds 1 through 100. Deterministic strategies still run 100 times to keep the aggregation procedure identical.
5
Report the median trial value for every metric and retain the minimum and maximum across the 100 trials.

Strategy details and variation

Deterministic strategies produced the same value in every trial. Full jitter changed with the seed, so its minimum and maximum are included below.

25 clients succeeded

Immediate retry

Retry after 1 millisecond, effectively remaining in the same service window.

Median success time: 0 ms
Last success: 0 ms
Total attempts range: 4,300 to 4,300
P95 success range: 0 ms to 0 ms

225 clients succeeded

Fixed delay

Retry every 500 milliseconds.

Median success time: 2.000 s
Last success: 4.000 s
Total attempts range: 3,600 to 3,600
P95 success range: 4.000 s to 4.000 s

225 clients succeeded

Exponential backoff

Start at 250 milliseconds, double each retry, and cap at 4000 milliseconds.

Median success time: 3.750 s
Last success: 19.750 s
Total attempts range: 3,600 to 3,600
P95 success range: 19.750 s to 19.750 s

500 clients succeeded

Exponential backoff with full jitter

Choose a seeded delay from 0 through the current exponential cap, with a 1 millisecond simulation minimum.

Median success time: 981 ms
Last success: 4.931 s
Total attempts range: 1,918 to 1,978
P95 success range: 2.503 s to 3.119 s

Recorded environment

This runner advances simulated time through queued events. The processor does not determine the simulated completion times, but the execution environment is recorded for reproducibility.

Runtime: Node.js 18.20.8
Operating system: Linux 5.14.0-687.5.4.el9_8.x86_64, x86_64
Processor: AMD EPYC 7713 64-Core Processor, 4 logical CPUs available
Performed: 2026-07-13

Observations

Immediate retry kept every rejected client inside the already saturated opening window. Only the first 25 clients succeeded, and the group generated 3,800 saturated retry attempts.
Fixed delay and exponential backoff created synchronized waves. Each new wave admitted 25 clients, so both strategies completed 225 of 500 clients before the retry limit.
Full jitter completed all 500 clients in every seeded trial. Its median trial used 1,956 total attempts and produced a median peak of 248 retry attempts in one 100 millisecond window.
Full jitter had a median total peak of 708.5 attempts in one window because some early retries landed in the opening window with the original 500 requests. Randomization spread later retry waves, but it did not reduce every peak metric.
The 95th-percentile success time for full jitter had a median of 2.686 seconds across the trials. The recorded range was 2.503 to 3.119 seconds.

Limitations

This is a discrete event simulation, not a live network or provider measurement. Simulated milliseconds are not wall-clock timings.
The service uses aligned fixed windows. Token buckets, rolling windows, adaptive throttles, concurrency limits, and distributed limiters can behave differently.
All 500 clients start together with identical policies and no network latency. Real traffic has timing variance, multiple client versions, and other sources of contention.
The simulation does not model a Retry-After response. A client should honor valid provider instructions before applying its local retry policy.
Request safety and idempotency are outside this model. A retry schedule does not make a non-idempotent operation safe to replay.
Success-time statistics include only clients that succeeded. A strategy with many final failures can therefore show a short success time for its small successful subset.
The full-jitter ranges belong to seeds 1 through 100 and this Mulberry32 implementation. Different seeds or random generators can produce different individual trials.
These results do not establish one universal retry policy. They show how four policies behave under the exact published scenario.

Reproduce the simulation

The public runner performs the complete deterministic event simulation and prints the scenario, environment, median metrics, and trial ranges as JSON. It makes no network requests.

node retry-strategy-simulation.mjs

Open simulation runner

Runner SHA-256d58dc1c15a054acfa17086d03d9844b32282c0ba29d33b8b06a47fe3e31bc977

Specifications and background

Exponential Backoff and Jitter AWS Architecture Blog
RFC 9110, Retry-After RFC Editor