This page explains which Cloud Storage operations are strongly consistent andwhich are eventually consistent. In the case of cacheable, publicly readableobjects, you control the degree to which operations on the objects areconsistent.

Strongly consistent operations

Cloud Storage provides strong global consistency for the followingoperations:

• Bucket listing
• Bucket read-after-create
• Bucket read-after-metadata-update
• Bucket read-after-delete
• Object read-after-write
• Object read-after-metadata-update
• Object read-after-delete
• Object listing

When you write an object to Cloud Storage, such as when you upload,compose, or copy an object, the object is immediately available for reading andmetadata operations as soon as you receive a success response to your writerequest. This is true for all buckets and for all storage classes, andthis applies to both creating new objects and replacing existing objects.Cloud Storage also offers read-after-create, read-after-metadata-update,read-after-delete, and listing consistency for resources such as folders andmanaged folders.

Because writes are strongly consistent, you never receive a404 Not Foundresponse or stale data for an object read-after-write or objectread-after-metadata-update operation, even for buckets located indual-regions or multi-regions. In the rare event where your data hasnot yet beenreplicated across regions, but the location your objectwas first written to becomes unavailable, attempts to access the object returnaretryable500 error response.

Strong global consistency also extends to deletion operations on objects. If adeletion request succeeds, an immediate attempt to download the object or itsmetadata results in a404 Not Found status code. You get the404 errorbecause the object no longer exists after the delete operation succeeds.

Bucket listing and object listing are strongly consistent: when you create abucket or object and then immediately perform the relevantlist operation, thenewly created bucket or object appears in the returned list.

Important: Cached objects that are publicly readable might not exhibit strongconsistency. SeeCache control and consistency for details.

For buckets, while metadata updates are strongly consistent forread-after-metadata-update operations, the resulting configuration changes maytake time to propagate. For example, if you enableobject versioning on abucket, you should wait at least 30 seconds before deleting or replacingobjects.

Similarly forHMAC keys, there is a delay of up to 3 minutes betweenwhen you request to change the key state and when the state change takes effect.For example, if youdisable an HMAC key, you should wait at least 3minutes before making a request to delete the key, because attempts to do so inthe first 3 minutes could fail.

Eventually consistent operations

The following operations are eventually consistent:

• Granting access to or revoking access from resources.
• Recreating buckets after deletion.

It typically takes about a minute for these operations to take effect. In somecases, it might take several minutes longer.

As an example of behavior that can arise from eventual consistency, if youremove a user's access to a bucket, this change is immediately reflected in themetadata for the bucket; however, the user may still have access to the bucketfor a short period of time.

Buckets that are recreated after deletion might take several minutes to becomeaccessible.

Cache control and consistency

Cached objects that are publicly readable might not exhibit strong consistency.If you allow an object to be cached, and the object is in the cache when it isupdated or deleted, the cached object is not updated or deleted until itscache lifetime expires.

The cache lifetime of an object is defined by theCache-Control metadataassociated with the object. TheCache-Control metadata can be set using aCache-Control request header included in the initial upload of the object,or in a subsequentupdate to the metadata of the object. Because youcontrol theCache-Control metadata, you also control the degree to whichcached objects are consistent. Moreover, while requests forthe object can include their ownCache-Control header, these headers areignored by Cloud Storage if they're set to avoid cached content.

Note: If you do not specify a cache lifetime, a publicly accessible object canbe cached for up to 60 minutes.

Atomic operations

Cloud Storage provides atomicity guarantees for most operationsinvolving individual objects, such as uploading an object, updating an object'smetadata, overwriting an object, and deleting an object.

Batch requests, which aggregate individual operations into a single request, arenot atomic, because it's possible for some of the operations contained withinthe batch to fail while others succeed.

Caching can cause you to receive stale versions of an object, and if youperform ranged reads without specifying a generation number, your datamight become corrupted if the object becomes overwritten between successiveranged reads. As a best practice, usepreconditions to make sure you'refetching the correct object version.

What's next

• Learn about usingpreconditions to prevent race conditions.
• Learn more aboutcaching in Cloud Storage.
• Learn aboutrequest rate and access distribution guidelines.