-
Notifications
You must be signed in to change notification settings - Fork 431
Clarify event id vs. "at-least-once" delivery #694
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
Conversation
This came up again recently and it seems that the relation should be further elaborated. Random UUIDs are not suitable in certain situations (without intermediate persistence), even though they are guaranteed to be "unique from the perspective of the owning application", as required in rule 211.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx. looks good -- just two minor change proposals.
Address review comments.
@tfrauenstein thank you for your comments! Do you think it is appropriate here to touch upon the two common strategies for publishers to ensure stable event id on retry, namely: intermediate persistence and consistent hashing? |
Yes, adding a 'design hint' might be helpful here, if it is not too long. |
Add design hint for stable eid on retry.
👍 |
@a1exsh sorry for the long delay and thanks for the contribution. Bad timing with Cyber Week and the prepared restructuring. Can you please resolve the conflict? Than I would also approve and merge the change. |
@tkrop @tfrauenstein please have another look |
👍 |
1 similar comment
👍 |
This came up again recently and it seems that the relation should be further elaborated.
Random UUIDs are not suitable in certain situations (without intermediate persistence),
even though they are guaranteed to be "unique from the perspective of the owning application",
as required in rule 211.