[jasonpeacock]

This is a general problem in all distributed systems, not just when pulling configuration from S3.

Let's assume you had strong consistency in S3. If your app is distributed (tens, hundreds, or thousands of instances running) then all instances are not going to update at the same time, atomically.

You still need to design flexibility into your app to handle the case where they are not all running the same config (or software) version at the same time.

Thus, once you've built a distributed system that is able to handle a phased rollout of software/config versions (and rollback), then having cache inconsistency in S3 is no big deal.

If you really need atomic updates across a distributed system then you're looking at more expensive solutions, like DynamoDB (which does offer consistent reads), or other distributed caches.

[mgdev]

The deeper in your stack you fix the consistency problem, the simpler the rest of your system needs to be. If you use S3 as a canonical store for some use case, that's pretty deep in the stack.

> Thus, once you've built a distributed system that is able to handle a phased rollout of software/config versions (and rollback), then having cache inconsistency in S3 is no big deal.

But this would also mean you can't use S3 as your source of truth for config, which is precisely what a lot of people want to do.

[nelsonenzo]

What I need is that when I make a call to a service, it gives back consistent results. Ergo, when the app does do a rolling deploy, it will get the right config on startup, not some random version.

It looks like it does exactly that now, it just wasn't clear from the article.