3 ms·
>> we remove the need for idempotency through deduplication. > If the client generates and assigns a UUID to each message it sends, the receiver can easily che
by mankyd 4y ago
>> we remove the need for idempotency through deduplication.
> If the client generates and assigns a UUID to each message it sends, the receiver can easily check if a specific message was already received before by comparing it against previously received UUIDs and can discard duplicates.
You quoted the part of the article that suggests exactly your solution: deduplication.
- jongjong 4y agoYes but the author suggests that it's difficult to perform or requires constructing messages in a complicated way which is not the case. Generating and attaching a UUID to a message is very simple, so is checking whether or not a UUID has already been encountered on the receiver side. The author's definition of 'message delivery' is incorrect and so is the title which is clickbait.
- greggyb 4y agoPerhaps adding a UUID is too much overhead? If you have a very high throughput system with messages of less than 128 bits, then the addition of a UUID to every message would effectively cut throughput in half. I do not have such a use case in mind, but the description above does not sound terribly unrealistic to me.
- datadata 4y agoAlso in order to track UUIDs that have been received, you would either need an infinite amount of memory, or have the system bounded in terms of how many messages out of order a message be delivered and still be processed correctly.
- jongjong 4y agoYou can use a database. Practically, most systems will keep a record of each message on disk in any case (at least they will have some logs) so it's not that outrageous. Safe to assume that the receiver can discard non-authenticated messages to avoid spam.
- datadata 4y agoIt depends entirely on volume of messages vs available memory (ram or disk) how outrageous it is