Strong Consistency: The "Read-After-Write" Guarantee

The Old Problem: Eventual Consistency

Imagine you write a note on a whiteboard and immediately ask someone across the room to read it — but they are looking at a copy of the whiteboard that updates with a few seconds of delay. For a brief window, they see the old version. This is what "eventual consistency" means in distributed storage systems: all copies will eventually agree, but there is a window where they might not.

For many years, S3 operated this way. If you uploaded a file (photo.jpg) and immediately tried to download it, S3 might return a 404 Not Found for a few seconds while the data propagated across the storage nodes inside the data center. This forced developers to write defensive "retry" logic and made S3 unsuitable for certain real-time pipeline patterns.

The New Reality: Strong Consistency (December 2020)

AWS redesigned S3's internal metadata subsystem to provide Strong Read-After-Write Consistency automatically, for free, in all regions. No configuration required.

What this means in practice:

• The moment you receive a 200 OK from a PUT (upload), a subsequent GET (download) or LIST on that object is guaranteed to reflect the new data.
• This applies to new objects, overwrites, and deletes. If you delete an object and immediately LIST the bucket, the deleted object will not appear.
• There is no performance penalty. AWS achieved this without sacrificing throughput or adding latency.

Architectural implication: You can now use S3 as the shared storage layer for distributed big data frameworks like Apache Spark or Hadoop without needing a separate coordination database (like DynamoDB) to track "what has been written." This simplifies the architecture of data lakes significantly.