Websites are moving towards providing md5/sha1/sha256 hashes of your normalized email (stripping the + from gmail) or phone number to advertisers.
A basically permanent ID. Unified ID2 is one version of this.
The 3rd party cookie ban and heavy pushback against alternative solutions suggested by Google just pushed advertisers into going an even worse route privacy wise.
Dumping third-party cookies is going to cause people's privacy to end up in a way worse position.
Almost all of ad tech is moving towards identifiers like hashed normalized emails (e.g. removing +'s from gmail), phone numbers, names, etc. for personalized ads.
If you use etags it's up to R2. I'm assuming R2 is consistent here.
So if you write to the same file twice, one write will succeed before the other and change the etag of the file, which should in theory cause the other request to R2 to fail because the etag you send with as conditional no longer matches.
Couldn't the library implement a conditional operation using the etag, retrying if it fails? That should solve the consistency guarantee.
Ofc its a different matter if you write to the same key in the same file. But that could be solved with special method that allows you to do a setOrUpdate on a key in the json and when retrying the update method is executed again (allowing you to do increments or add a new item to an array) while guaranteeing consistency.
Here in the Netherlands they decided to increase the water level of our lakes by 5cm to handle the drought season this year. Since the amount of snowfall in the Alps was lower than normal.