While DynamoDB doesn't preserve the insert records order, we can sort the message records by the timestamp of its creation and create
a rule for sorting them inside the DynamoDB to preserve the delivery FIFO order.
Linear task: ENG-1027
Details
Details
Passed test at D3806.
Run yarn test-tunnelbroker-service all tests are run and succeed.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- message-timestamp
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
Can't we just sort by message id? Is there a reason to avoid that?
Could two different messages have the same timestamp?
Comment Actions
We use UUID-based messageID on the randomly generated string because the messageID must be unique - we will remove the delivered message by the unique id.
The message's timestamps theoretically can be the same in case they were sent at the same time. We can also use an atomic counter, but its realization in dynamoDB is not good.
I think using the timestamp (second or millisecond) is a better idea here.
Comment Actions
Ok, that makes sense. But I'm not sure if this will work when there are multiple instances of the service. Do we need the clocks to be closely synchronized? Or maybe, we don't need to keep an order of messages handled by different instances?
Overall, this looks ok, but adding @ashoat to get his opinion
Comment Actions
Adding more context here:
We are using the timestamp to preserve the order of the messages. There is only another option with the atomic counter, we can consider it too. In DynamoDB we should maintain this counter and read/increment it. DynamoDB doesn't have an auto-increment (( The records order preservation is not guaranteed either they are sorted somehow.
Comment Actions
This makes sense to me.
Do we need the clocks to be closely synchronized?
Ideally, yes. But it's not the end of the world if they aren't perfectly synchronized, as long as everybody agrees on the order of the events.
Or maybe, we don't need to keep an order of messages handled by different instances?
I do think this will be necessary. If User A and User B send User C a message at the same time, those two messages will both get queued from User A's and User B's Tunnelbroker instances.