Disagree. Considering the original goal had nothing to do with expecting S3 to go down, it just happened to be super useful during this incident. We get more more benefits even without S3 breaking.
It's not uncommon for applications to have MRU access patterns and be able to keep partially functioning during partial data availability. For these applications, a cache will lower costs and mitigate S3 outages. It would have been nice for the article to give the criteria up front.
That paragraph says your connection to S3 is slow. Your solution doesn't fix general S3 slowness. However, it does make S3 slowness less of a problem for your application.
That's why it would have been useful to describe how your application accesses S3, so others can quickly determine if their applications would also benefit from a similar solution.
For example: "90% of our S3 reads are of blobs that were read in the last 30 days."
Many applications might upload data to S3, then quickly download it for processing. For those applications, this solution won't work.
> But I never set out to mitigate S3 failures like this.
We know. It's just that some people might read the title and think this is a more general solution than it is. OP was just warning people against that.