Just curious anyone who uses DynamoDB & does a...
# randomg
Garret Harp
01/22/2022, 8:31 PMJust curious anyone who uses DynamoDB & does aggregations how do you handle idempotency specifically at high velocity writes. At high speeds updating the same item for aggregation causes a lot of transaction conflicts because Dynamo does not allow 2 transactions to update the same attribute even if you are not doing any condition checking on the update.
o
Omi Chowdhury
01/22/2022, 11:40 PMWe wrap the aggregation code in a retry internal to the lambda, and that lambda is feeding off an SQS queue which will retry on top of that. Otherwise we use $add updates as much as possible, and break down the whole aggregations into multiple smaller chunks, that writes intermediate steps of the aggregation into dynamo (these intermediate aggregations are useful in their own right, so we would need to tally them anyway).
Omi Chowdhury
01/22/2022, 11:42 PMAt a certain point the only way to scale that aggregation write load is to shard the the, and add another aggregation step.
s
Seth Geoghegan
01/23/2022, 3:55 PMNot sure if it applies to your use case, but you could consider optimistic locking to solve this problem.
Seth Geoghegan
01/23/2022, 3:55 PMIn summary:
Each item gets a version counter that's incremented once you update it. When you want to update an item, you first read it and store the current version number. Then you perform your update and increment the version number. Now you need to write it back to the table and this is when you add a condition. The condition is that the current version of the item needs to be the same as it was when you read the item originally. If that's not the case the write should fail, because somebody else modified the item in the mean time.
g
Garret Harp
01/23/2022, 4:01 PMOptimistic locking is actually the problem I'm trying to get around. You cannot update the same attribute on an item twice at the same time otherwise you get a transaction conflict error.