In DynamoDB global tables, if one region receives a delete request on a record, and another region receives update during the same time, how can we ensure the Delete operation takes precedence and the record does not live after the conflict resolution. In other words can we achieve Strong Delete Consistency for global tables?
2 Answers
0
votes
Are you looking for the update to fail with error, or is it enough that the record get deleted if it was deleted prior to the update?
If the latter, then that’s pretty much what would happen: the items get deleted; sometimes before the update, other times after; but they always get deleted. The only difference is that some of the updates would appear to succeed while other would fail, depending on order of operations
However, if you need the updates to always fail then I’m afraid you need to come up with a distributed global lock: it would be costly and slow.
If you want to see for yourself, I recommend setting up a test: create a global table and add a bunch of items (say 10,000) and then, with two DynamoDB clients from the same EC2 instance, perform DELETE and UPDATE requests in two different regions in a tight loop. At the end you should see that all items are deleted.
0
votes
You will never be able to guarantee strong consistency for global tables.
However, it sounds like there is a specific race condition you are trying to prevent where an update overwrites a delete, and that is possible to prevent.
The simplest way to guarantee that a delete is not followed by an update is by using a specific region as the “master” region for every item. If you need to update or delete the item, use the endpoint for the master region. The drawback is that cross-region writes will have much higher latency than same region writes. However, this may be an acceptable trade-off depending on the details of your application.
How do you go about implementing this? You could add a regionId attribute to your table, and every time you create an item, you set a specific region which should be the master region for that item. Whenever you go to update/delete an item, read the item to find the item’s master region and make the update/delete request to the appropriate regional endpoint.
So that’s the principle, but there’s actually something to make it even easier for you. DynamoDB adds a few special attributes to all items in a global table (see Global Tables – How it Works), and one of those attributes is aws:rep:updateregion which is the region where it was last updated. Just make sure when you need to update or delete an item, you read that attribute and then use the endpoint for that region to make the update/delete request.
