You need ordered delivery of messages, but only at user level (if all messages needed to be ordered you could not do this sharding type setup). Is there a way to apply shuffle sharding while maintaining user-level ordering guarantees?
And on a personal note, I’m astounded and so lucky that I get to work with these amazing engineers!
Wowzer. Amazon, and in particular AWS, sits on a treasure trove of hard-earned lessons abt designing, building, operating, maintaining systems at scale. I'm glad they have began to share some of that know-how with the external world.
I wrote abt longing for AWS to do this some 6 months back  as I dearly missed access to those docs and videos that helped me understand so much abt the underpinnings of some of the most staunchest challenges dealt with by behemoth-esque services like S3, EC2, Redshift, DynamoDB, Kinesis, LB, Lambda, Edge, Security to name but a few.
I must point out though, re:invent does have a ARC track  which gives glimpses into AWS' design principles.
There's so much they could still share (for instance, abt how they track and run their operations, how they deal with service outages, how they do change management, how they continuously monitor and improve the weaker and slower parts of the systems, how they gear up for launches, how they deal with issues facing larger customers, how they go abt their design process, how they refine their internal tools and processes, the internal tech talks, the review meetings esp the one run by Charlie Bell...), and I'm glad they've committed to be doing just that.
It'd be fun comparing literature coming out of Amazon to what's published by Google et al.
This made me laugh hilariously.
But overall the parent was a very helpful comment, to get this perspective from an ex-Amazon-er
1. Make sure your first paragraph or executive summary answers the questions: Why does this doc exist? Who is the expected audience? What actions or decisions does the author expect from the audience after reading the doc?
2. Run things through an analyzer like Hemingway. It'll point out obvious things to fix.
3. Do a reverse-thesaurus editing pass. Remove adjectives and flowery language where possible. Challenge yourself to lower the reading level. Even if your audience has PhDs they'll read and comprehend simple language faster.
4. Do an editing pass for missing numbers. Vague language, unsupported assertions, and missing quantities make arguments easy to refute. Look for words like "many", "most", "a lot", "major" "severe" "large" and replace them with hard numbers where possible.
5. Do an editing pass for "So, what?" and remove anything that isn't necessary to support your core argument or purpose. Assume your audience is smart but has very little time. Too much detail will make them start to skim and miss things. Appendixes are your friend here. Leave links to appendixes for readers that have questions or want more detail.
6. Nothing beats a human reviewer. Professional writers have editors too.
One way to encourage this helpful criticism is for authors to accept feedback gracefully and have a policy to ask questions only for clarification of the feedback (to understand the feedback better) and never to engage in the debate response of explaining why what they wrote is good enough.
(The minute you debate them on the first of seven points they have, they’re going to deprive you of much of the value of their feedback on the next six because you’re seeming defensive at worst or exhausting at the least.)
I wonder if this is simply because human brains are just create specialized neural pathways for special tasks that occur more frequently. So it takes a lot of effort for someone who has never driven a car to drive but after they learn driving it’s automatic (same for language and any other skill)
But you'll get the best results by putting a lot of directed and specific practice into it. Ben Franklin wrote about his method in his autobiography. He would try to reproduce passages he admired from memory. Then he would check his work and repeat until he reproduced it verbatim. Then he would repeat but try to improve it.
When I started at amazon I was encouraged to pitch a project or feature once a month. More importantly I was encourage to write up things I disagreed with or try to sell stuff that was very half assed, and work on getting it to a real idea.
As I did this I got better and better. I can write up 3-5 page design docs in about 1-2 hours now and these can bootstrap others into your thinking very easy. I've found that they also just ground an argument when everyone is arguing about totally different things. Even if they are now all arguing AGAINST your idea, you've made progress.
It's just a muscle you have to exercise. And iterate with feedback. Learn from where people have trouble understanding your document. If they don't understand it, take it as feedback that you are not clear enough.
TLDR Write Write Write
(I worked there 2006-2016)
> I'm convinced it's a major reason they've been so successful.
I'd be interested to hear why you think this.
One guess I've got is that a high standard for writing is a filter for bad ideas - if you can't justify your idea in a tight, well-written document, then it's probably not worth trying out.
One option might be to change the URL on this submission to the blog post about the list instead: