Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion to use uuid for message_id instead of random string #19

Open
shashankshet opened this issue Nov 21, 2023 · 1 comment
Open

Comments

@shashankshet
Copy link

Hello Team,

This looks like a wonderful project, kudos to the developers who developed this.
I see we are using random str for message_id, rather than using random string i suggest we can use uuid4, to achieve more randomness in the id.
UUIDs (Universally Unique Identifiers) are designed to be globally unique across space and time. The probability of generating the same UUID is extremely low.

If you agree on this, I would love to contribute to this project, please let me know your thoughts on this suggestion

@mlasevich
Copy link
Owner

Honestly, while I see your point, I do not think it will be an improvement:

Core reasons to not do it:

1 - This implementation mirrors other implementations of the RSMQ. Consistency has value.
2 - Using UUID will increase storage requirements (36 bytes vs 30 bytes per id)
3 - Using UUID will increase probability of collision, UUID4 gives you 128 bits total (including timestamp) vs current implementation gives us (almost) 132 bits of randomness PLUS a usec timestamp

On the other hand:

1 - UUID is a more standard way to do this in general, even if it is not consistent with what other RSMQ implementations do
2 - I need to look into it a bit more, but I believe while consistency is nice, I am pretty sure it is not required for interoperability with other implementations
3 - Extra 6 bytes per record is not that big of a deal
4 - Collision probability, while different, is mostly academic, UUID collision maybe more probable, but the difference is negligible and the world agrees that UUID is good enough.

In the end, lack of notable benefit combined with inconsistency with other implementations make me say it is probably a waste of time - however, if you really want to, maybe we can make this a selectable option, so that if someone really wants to, they can choose a UUID generator in place of a standard one.

HTH

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants