If I create or update a file in one region and immediately call list in another region (such that the list’s prefix would contain the file’s key) is the list guaranteed to see the new/updated file? Or is it possible the list will return cached data that does not include the new/updated file?
There is a chance you won’t see the file. Tigris is globally eventually consistent. When you upload a file to one region, that metadata is replicated to all the other regions. If you make a list query to another region before the replicated metadata has reached that region, the query won’t include the file.
You can use our new object notifications if you want to receive a webhook for each new object change.
Hope that helps.
Cheers
Garren
Thanks for details! I assume that requests within one region should have read after write consistency though? If my app depends on that, should I somehow pin my requests to particular regions?
@f0a That is right. We offer strong consistency for the same regional requests. For list requests, we offer eventual consistency globally and strong consistency in the same region which means there is a possibility when a write happens in region A and list happens in region B then the request may not see the recent created objects(till the time it replicates to region B)
For multi-regional GET requests i.e. when a write happens in region A and if read happens in region B then Tigris will automatically return you this object from A unless an older version of the object is present in region B(in progress replication - concurrent modification scenario).
I am assuming you have a use-case where a write can happen in any region but list needs to be strongly consistent?
Ah interesting. So if I create a new file that didn’t previously exist in region A and then attempt to immediately read it from region B it will return the file rather than reporting 404? That’s useful to know.
I am building a storage engine that supports transactions and is backed by object storage. I need to understand the specific semantics of Tigris in order to use it as effectively as possible. Given this information, I’ll be sticking with my original plan of pinning metadata to regions such that I don’t have to worry about the async nature of metadata replication in Tigris (which makes total sense and I wouldn’t ask for a different model due to performance).