Build1 publisherNot yet confirmed elsewhere2 min readPublished
AWS cuts DynamoDB retries from 9 to 4 next November, and the flag to test it is already live
The November 1, 2026 SDK retry defaults change behaviour under partial failure with no code change on your side. One author's synthetic run projects failures going from 6 to 27 per 1,428 calls.
The Engineer · Build desk
What happened
- AWS is changing default retry behaviour across its SDKs for Java, Python, JS, Go and PHP, plus the CLI, on November 1, 2026.
- DynamoDB's per-service override drops from a maximum of nine attempts to four; most other services go from four to three.
- Java SDK 2.44 and later already accepts AWS_NEW_RETRIES_2026=true as a binary opt-in to the new defaults.
- In a synthetic DynamoDB, S3 and SQS run, the new defaults project 27 failures across 1,428 calls against 6 observed today.
- The post's author published retrylens, an SDK interceptor that records attempts and replays them against the 2026 settings.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Services that never wrote a retry policy are the exposed ones: the nine-attempt DynamoDB tail was a default they inherited, and it disappears without any code of theirs changing.
- decision A measured extra-failure count turns this into a funded choice between buying write capacity and pinning a per-operation retry override, rather than an item deferred until dashboards move.
- constraint Existing telemetry cannot size the risk, because the retry loop reports only the final outcome, so no team can estimate its exposure from the logs it already keeps.
- capability Replaying recorded attempt outcomes as arithmetic makes it possible to price the change against live traffic without credentials, a second environment, or reissued requests.
The two report blocks in that dev.to post reconcile exactly, which is worth checking before trusting anything else in them. Observed retries were 409, projected retries 186 [15][16], and the 223 difference is the entire attempt reduction the author reports [3]. So the simulation is not trimming a tail. It removes 55 percent of all retrying in that workload [19]. Failures move the other way, 6 to 27, a 4.5x increase [23], or 0.42 percent of calls to 1.89 percent [24].
The throttled count is 118 in both reports [15][16]. That is the model's central assumption and the reason the output is legible: the hostile environment is held constant, and only the budget for surviving it changes [25].
The concentration is the part worth carrying into a capacity conversation. DynamoDB PutItem accounted for 310 of the 1,428 calls but 188 of the 409 retries [4][15], which is 0.61 retries per call against S3 GetObject's 0.12 [20]. That is what nine attempts buys, and it is why the change lands on write paths rather than reads. The author asserts that many write paths quietly depend on that longer tail, and that a real number of writes that succeed today will fail on the first of November [26].
Measured as budget, DynamoDB loses 56 percent of its attempts while everything else loses 25 percent [21]. The 9-attempt setting was a per-service override, not a general default [2], so this is a carve-out being withdrawn rather than a dial being nudged. Backoff moves in both directions at once: the transient-error base delay is halved to 50 ms, while the throttling base delay doubles to 1,000 ms [8][9]. Two exception types, LimitExceededException and STS IdpCommunicationErrorException, become retryable [10], which pushes a small amount of traffic back the other way.
Now the caveats, which the author states plainly. retrylens does not model standard mode's retry quota, the token bucket that suppresses retries under sustained failure, so its figures are an upper bound on how much retrying the new mode would actually do [6]. Fewer real retries than modelled means at least as many retry exhaustions, so the +21 reads as a floor on extra failures, not a worst case [22]. And the snapshot is a synthetic DynamoDB, S3 and SQS workload [15] measured by a library the post's author wrote and published [13]. It demonstrates a method. It is not a measurement of your fleet, and nothing here is corroborated by a second publisher.
What to watch
- Whether AWS issues per-service guidance for DynamoDB write paths, or lets the 9-to-4 cut land as a flat default with no carve-out.
- Whether the Python, JS, Go, PHP SDKs and the CLI get an early opt-in equivalent to the Java 2.44 environment variable, or arrive cold on November 1.
- Whether anyone publishes an attempt-distribution measurement from real production traffic rather than a synthetic workload.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence46
- Adoption16
- Hype gap+22
- Incentives72
- Confidence41
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Max attempts for most services changes from 4 to 3.
- [2]
DynamoDB max attempts changes from 9 to 4; DynamoDB has always had a per-service override allowing up to nine attempts before giving up.
- [3]
The report states a delta of -223 attempts, mostly DynamoDB PutItem moving from a 9-attempt cap to 4, and +21 failures as PutItem exhausts retries sooner under sustained throttling.
- [4]
DynamoDb.PutItem in the observed snapshot: 310 calls, 498 attempts, 188 retries, 12 throttled, 2 failures, p50 31 ms, p95 410 ms, with ProvisionedThroughputExceededException=12 as top error.
- [5]
S3.GetObject in the observed snapshot: 812 calls, 912 attempts, 100 retries, 0 throttled, 0 failures, p50 8 ms, p95 41 ms.
- [6]
retrylens does not model standard mode's retry quota, the token bucket that can suppress retries under sustained failure, so its numbers are an upper bound on how much retrying the new mode would do.
- [7]
AWS is changing default retry behaviour in every one of its SDKs (Java, Python, JS, Go, PHP) plus the CLI as part of a cross-SDK announcement, effective November 1, 2026.
- [10]
LimitExceededException and STS IdpCommunicationErrorException become retryable under the new defaults.
- [11]
You can opt in early on AWS SDK for Java 2.44 or later by setting AWS_NEW_RETRIES_2026=true, but it is a binary switch and the only way to know if it hurts is to flip it and watch.
- [12]
The SDK's retry loop is largely invisible from the outside: logs show either a successful result or a final failure, not the attempts in between.
- [13]
The post's author published a library called retrylens on Maven Central and GitHub that attaches a single ExecutionInterceptor to any AWS SDK v2 client, records every attempt into a bounded ring buffer, and simulates what the November 2026 defaults would have done to that traffic.
- [14]
The simulator is a pure function over recorded outcomes: it never re-issues a request, never talks to AWS, and never needs credentials.
- [15]
Observed snapshot from a synthetic DynamoDB, S3 and SQS workload: calls=1428, attempts=1837, retries=409, throttled=118, failures=6.
- [16]
Projected under STANDARD_2026 for the same workload: calls=1428, attempts=1614, retries=186, throttled=118, failures=27.
- [17]
Sqs.ReceiveMessage in the observed snapshot: 201 calls, 253 attempts, 52 retries, 83 throttled, 3 failures, p95 2.10 s, with RequestThrottled=83.
- [18]
The author frames the choice as raising DynamoDB write capacity, setting a per-operation retry override, or accepting the drop as within budget, and says 21 extra failures per 1,428 calls is a specific claim you can take to a design review.
- [19]
Retries fall from 409 to 186, a reduction of 223 that accounts for the whole reported attempt delta, and removes 54.5 percent of all retrying in the workload.
- [20]
DynamoDB PutItem ran 0.61 retries per call against S3 GetObject's 0.12, and produced 46 percent of all retries from 21.7 percent of all calls.
- [21]
DynamoDB loses 56 percent of its attempt budget while most other services lose 25 percent.
- [22]
Because the model allows more retrying than the token bucket would permit, real retry-exhaustion failures are at least as many as projected, making the +21 a floor rather than a worst case.
- [23]
Projected failures are 4.5 times the observed count.
- [24]
Failure rate rises from 0.42 percent of calls to 1.89 percent of calls.
- [25]
Throttled events are identical at 118 in the observed and projected reports, so the projection holds the throttling environment constant and varies only the retry budget.
- [26]
The author asserts that many write paths quietly rely on the longer retry tail to survive brief throttling bursts, and that a real number of writes that succeed today will fail on November 1.
ReportedInsufficientSource: Bibek Mhj, dev.to post author2 sources— create a free account to open themView cited source
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toPreview the November 2026 AWS SDK for Java retry defaults on your own traffic
1 article · August 22, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.