This page explains which Google Cloud Storage operations are strongly consistent and which are eventually consistent. In the case of cacheable, publicly readable objects, you control the degree to which operations on the objects are consistent.
Strongly consistent operations
Cloud Storage provides strong global consistency for the following operations, including both data and metadata:
- Bucket listing
- Object listing in regional locations
- Granting access to resources
When you upload an object to Cloud Storage, and you receive a success
response, the object is immediately available for download and metadata
operations from any location where Google offers service. This is true whether
you create a new object or overwrite an existing object. Because uploads are
strongly consistent, you will never receive a
404 Not Found response or stale
data for a read-after-write or read-after-metadata-update operation.
In addition, when an upload request succeeds, it means your data is replicated in multiple data centers. The latency for writing to Cloud Storage's globally consistent, replicated store may be slightly higher than for a non-replicated or non-committed store. This is because a success response is returned only when multiple writes complete, not just one.
Strong global consistency also extends to deletion operations on objects. If a
deletion request succeeds, an immediate attempt to download the object or its
metadata will result in a
404 Not Found status code. You get the
because the object no longer exists after the delete operation succeeds.
Bucket listing is strongly consistent. For example, if you create a bucket,
then immediately perform a
list buckets operation, the new bucket appears in
the returned list of buckets.
Object listing is also strongly consistent for all regional locations. For
example, if you upload an object to a bucket in a regional location and then
immediately perform a
list objects operation, the new object appears in
the returned list of objects.
For buckets, while metadata updates are strongly consistent for read-after-metadata-update operations, the resulting configuration changes may take time to propagate. For example, if you enable object versioning on a bucket, you should wait at least 30 seconds before deleting or overwriting objects.
Eventually consistent operations
The following operations are eventually consistent:
- List operations for objects in multi-regional locations
- Revoking access from resources
It typically takes about a minute for a change to be reflected in listing results or for revoking access to take effect. In some cases it may take longer. Some examples of behavior that can arise from eventual consistency:
- If you upload a new object to a bucket in a multi-regional location and then
immediately perform a
list objectsoperation on the bucket, the new object might not appear in the returned list of objects. The new object is still available for immediate use, even though it does not appear in the list of objects.
- If you delete an object in a bucket in a multi-regional location and then
immediately perform a
list objectsoperation on the bucket that contained the object, the deleted object might still appear in the returned list of objects. The deleted object is no longer available, even though it appears in the list of objects.
- If you remove a user's access to an bucket, this change is immediately reflected in the metadata for the bucket; however, the user may still have access to the bucket for a short period of time.
A bucket deletion operation can also be affected by the eventual consistency of list operations. This operation is only affected when you delete all of the objects in a bucket located in a multi-regional location and then immediately try to delete the bucket. In this case, the list of objects in the bucket might not immediately reflect the fact that the objects have been deleted, which causes the bucket deletion operation to fail.
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 is updated or deleted, the cached object will not be updated or deleted until its cache lifetime expires.
The cache lifetime is defined by the
Cache-Control request header, which you
can specify when you upload an object. Because you control the
header, you also control the degree to which cached objects are consistent.