How do event sourced systems guarrantee reliability in the event delivery
up vote
0
down vote
favorite
Since in event-sourcing the event store does not use transactions, how can we guarantee that, if our business logic crashes, after it publishes an event, that the event won't be published twice when restarting the service?
In the case that the message is published and delivered twice, how can it be de-duplicated?
messaging event-sourcing
asked Nov 21 at 13:11
tkiwi
417
add a comment |
up vote
0
down vote
favorite
Since in event-sourcing the event store does not use transactions, how can we guarantee that, if our business logic crashes, after it publishes an event, that the event won't be published twice when restarting the service?
In the case that the message is published and delivered twice, how can it be de-duplicated?
messaging event-sourcing
asked Nov 21 at 13:11
tkiwi
417
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Since in event-sourcing the event store does not use transactions, how can we guarantee that, if our business logic crashes, after it publishes an event, that the event won't be published twice when restarting the service?
In the case that the message is published and delivered twice, how can it be de-duplicated?
messaging event-sourcing
asked Nov 21 at 13:11
tkiwi
417
Since in event-sourcing the event store does not use transactions, how can we guarantee that, if our business logic crashes, after it publishes an event, that the event won't be published twice when restarting the service?
In the case that the message is published and delivered twice, how can it be de-duplicated?
messaging event-sourcing
messaging event-sourcing
asked Nov 21 at 13:11
tkiwi
417
asked Nov 21 at 13:11
tkiwi
417
asked Nov 21 at 13:11
tkiwi
417
asked Nov 21 at 13:11
tkiwi
417
asked Nov 21 at 13:11
tkiwi
417
417
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
I don't know that the event store does not use transactions. I've seen transactional writes to ensure that the expected event version is being written.
If you are expecting at-least-once delivery, which I assume you are, then you must handle deduplication. It is sometimes recommended to maintain an index of all processed messages as a de-duping approach, but it is not completely safe in that you just minimize the section of code in which a duplicate can be created, but don't remove the possibility altogether. If you process a message, but do not update the index then you will reprocess the same message again. You should instead make all of your actions idempotent. That is, performing the same action twice will produce the same resulting state. If you process the same message twice, it should only update state once.
answered Nov 21 at 15:38
CPerson
3266
Thanks. I have an additional question. I understand how the business logic should be idempotent. One problem that arises is that the emitted events will need to have new id's. If the id's are randomly generated however, which is the easiest solution, the emitted events won't be the same. How is this problem solved? Should we for example generate the id's based on a hashing algorithm, in an idempotent way as well?
– tkiwi
10 hours ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
I don't know that the event store does not use transactions. I've seen transactional writes to ensure that the expected event version is being written.
If you are expecting at-least-once delivery, which I assume you are, then you must handle deduplication. It is sometimes recommended to maintain an index of all processed messages as a de-duping approach, but it is not completely safe in that you just minimize the section of code in which a duplicate can be created, but don't remove the possibility altogether. If you process a message, but do not update the index then you will reprocess the same message again. You should instead make all of your actions idempotent. That is, performing the same action twice will produce the same resulting state. If you process the same message twice, it should only update state once.
answered Nov 21 at 15:38
CPerson
3266
Thanks. I have an additional question. I understand how the business logic should be idempotent. One problem that arises is that the emitted events will need to have new id's. If the id's are randomly generated however, which is the easiest solution, the emitted events won't be the same. How is this problem solved? Should we for example generate the id's based on a hashing algorithm, in an idempotent way as well?
– tkiwi
10 hours ago
add a comment |
up vote
0
down vote
accepted
I don't know that the event store does not use transactions. I've seen transactional writes to ensure that the expected event version is being written.
If you are expecting at-least-once delivery, which I assume you are, then you must handle deduplication. It is sometimes recommended to maintain an index of all processed messages as a de-duping approach, but it is not completely safe in that you just minimize the section of code in which a duplicate can be created, but don't remove the possibility altogether. If you process a message, but do not update the index then you will reprocess the same message again. You should instead make all of your actions idempotent. That is, performing the same action twice will produce the same resulting state. If you process the same message twice, it should only update state once.
answered Nov 21 at 15:38
CPerson
3266
Thanks. I have an additional question. I understand how the business logic should be idempotent. One problem that arises is that the emitted events will need to have new id's. If the id's are randomly generated however, which is the easiest solution, the emitted events won't be the same. How is this problem solved? Should we for example generate the id's based on a hashing algorithm, in an idempotent way as well?
– tkiwi
10 hours ago
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
I don't know that the event store does not use transactions. I've seen transactional writes to ensure that the expected event version is being written.
If you are expecting at-least-once delivery, which I assume you are, then you must handle deduplication. It is sometimes recommended to maintain an index of all processed messages as a de-duping approach, but it is not completely safe in that you just minimize the section of code in which a duplicate can be created, but don't remove the possibility altogether. If you process a message, but do not update the index then you will reprocess the same message again. You should instead make all of your actions idempotent. That is, performing the same action twice will produce the same resulting state. If you process the same message twice, it should only update state once.
answered Nov 21 at 15:38
CPerson
3266
I don't know that the event store does not use transactions. I've seen transactional writes to ensure that the expected event version is being written.
If you are expecting at-least-once delivery, which I assume you are, then you must handle deduplication. It is sometimes recommended to maintain an index of all processed messages as a de-duping approach, but it is not completely safe in that you just minimize the section of code in which a duplicate can be created, but don't remove the possibility altogether. If you process a message, but do not update the index then you will reprocess the same message again. You should instead make all of your actions idempotent. That is, performing the same action twice will produce the same resulting state. If you process the same message twice, it should only update state once.
answered Nov 21 at 15:38
CPerson
3266
answered Nov 21 at 15:38
CPerson
3266
answered Nov 21 at 15:38
CPerson
3266
answered Nov 21 at 15:38
CPerson
3266
3266
Thanks. I have an additional question. I understand how the business logic should be idempotent. One problem that arises is that the emitted events will need to have new id's. If the id's are randomly generated however, which is the easiest solution, the emitted events won't be the same. How is this problem solved? Should we for example generate the id's based on a hashing algorithm, in an idempotent way as well?
– tkiwi
10 hours ago
add a comment |
Thanks. I have an additional question. I understand how the business logic should be idempotent. One problem that arises is that the emitted events will need to have new id's. If the id's are randomly generated however, which is the easiest solution, the emitted events won't be the same. How is this problem solved? Should we for example generate the id's based on a hashing algorithm, in an idempotent way as well?
– tkiwi
10 hours ago
Thanks. I have an additional question. I understand how the business logic should be idempotent. One problem that arises is that the emitted events will need to have new id's. If the id's are randomly generated however, which is the easiest solution, the emitted events won't be the same. How is this problem solved? Should we for example generate the id's based on a hashing algorithm, in an idempotent way as well?
– tkiwi
10 hours ago
Thanks. I have an additional question. I understand how the business logic should be idempotent. One problem that arises is that the emitted events will need to have new id's. If the id's are randomly generated however, which is the easiest solution, the emitted events won't be the same. How is this problem solved? Should we for example generate the id's based on a hashing algorithm, in an idempotent way as well?
– tkiwi
10 hours ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53412832%2fhow-do-event-sourced-systems-guarrantee-reliability-in-the-event-delivery%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
