> For the complete documentation index, see [llms.txt](https://karansingh.gitbook.io/tutorialsdojo-wrong-answers/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://karansingh.gitbook.io/tutorialsdojo-wrong-answers/test-3-66/s3-consistency.md).

# S3 Consistency

* S3 provides **strong read-after-write consistency for PUTS of new objects** in your S3 bucket.<br>
  * **If you make a GET request to the key name (to find if the object exists) before creating the object, S3 provides eventual consistency for read-after-write**.<br>

* S3 offers **eventual consistency for overwrite PUTS and DELETES**.<br>

* **Bucket configurations have an eventual consistency** model.

  * Specifically:
    * **If you delete a bucket and immediately list all buckets, the deleted bucket might still appear in the list**.
    * **If you enable versioning on a bucket for the first time, it might take a short amount of time for the change to be fully propagated**.

* Updates to a single key are atomic.
  * For example, **if you PUT to an existing key, a subsequent read might return the old data or the updated data, but it will never return corrupted or partial data**.
    * This **usually happens if your application is using parallel requests on the same object**.<br>

* **If two PUT requests are simultaneously made to the same key, the request with the latest timestamp wins**.
  * If this is an issue, you will need to build an object-locking mechanism into your application.