Top all-time · #6700
AWS Architecture Blog
Company blog · awsarchitectureblog.comsystemsweb
AWS Architecture Blog is the company blog at awsarchitectureblog.com, writing about systems and web. Since 2014, 12 different Hacker News readers have linked it 14 times, most often “Exponential Backoff and Jitter”. It is still writing: the last post was on 2026-10-29, and you can follow it by feed.
Too few sampled comments (4) to say how often HN recommends it.?
Why HN links it
HN readers link this blog for its posts on exponential backoff and jitter for retries in distributed systems, including Marc Brooker's backoff post with graphs comparing jitter approaches.
Summarised by Claude from a sample of 4 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Most-linked posts?
- Exponential Backoff and Jitter5 people · 5 mentions · first linked 2015-03-05
What Hacker News says?
I have no doubt they would have been using randomised exponential backoff -- these issues are well recognised inside Amazon and best practices are well known. For example, here's a blog post from March this year from Marc Brooker on the topic: http://www.awsarchitectureblog.com/2015/03/backoff.html . It may not have been correctly tuned for this scenario however. I'd say the Dynamo team are well aware of what they s…
Comment linking /2015/03/backoff.html
on “Summary of the Amazon DynamoDB Service Disruption”Submitted Exponential Backoff and Jitter as a story · 85 points
HN discussionAbsolutely. I made some graphs of different kinds of jitter approaches at http://www.awsarchitectureblog.com/2015/03/backoff.html . Simply backing off with delay does very little to spread out spikes of work, and can lead to longer MTTRs if the cause of the issue was overload.
Comment linking /2015/03/backoff.html
on “Lessons learned writing highly available code”Submitted Shuffle Sharding: massive and magical fault isolation as a story · 50 points
HN discussion[Full disclosure: I've worked on Amazon Route 53] It's always neat to see nice data collection like this, but unfortunately the average speed to the authoritative name servers isn't a very meaningful measurement. Real world resolvers bias heavily towards the fastest name server for your zone, and they are so latency sensitive that they'll do things like issue concurrent queries to several name servers at the same ti…
Comment linking /2014/05/a-case-study-in-global-fault-isolation.html
on “Worldwide DNS Performance”Submitted Organizing Software Deployments to Match Failure Conditions (2014) as a story · 15 points
HN discussionThat's nice, but what about adding backoff? I just came across this blog post[1] over at AWS about exponential backoff - timely because I'd just been working on some retry logic myself and wondered if I'd made good decisions about how to implement jitter. Turns out, I hadn't. [1] http://www.awsarchitectureblog.com/2015/03/backoff.html
Comment linking /2015/03/backoff.html
on “Try Three Times”Submitted Exponential Backoff and Jitter as a story · 5 points
HN discussionSubmitted Exponential back off and jitter (2015) as a story · 3 points
HN discussionSubmitted AWS and Compartmentalization as a story · 3 points
HN discussionSubmitted Internet Routing and Traffic Engineering as a story · 2 points
HN discussionSubmitted Shuffle Sharding: massive and magical fault isolation / AWS / Cloud as a story · 2 points
HN discussionSubmitted Doing Constant Work to Avoid Failures as a story · 1 points
HN discussionSubmitted (Amazon Route 53) A Case Study in Global Fault Isolation as a story · 1 points
HN discussion
