Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: emit transaction lifecycle events #244
feat: emit transaction lifecycle events #244
Changes from all commits
022ed99
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
If the event bus send fails for these calls is the
ledger_transaction
also rolled back?I think my overall question is this: When these event emissions fail to send, should the related DB writes also fail?
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.
No, because then we're making the communication pattern synchronous instead of asynchronous.
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.
But if the event doesn't make it on to the bus, and the record is written, systems downstream of this message will not be able to act accordingly. Not having this event hit the bus means that whatever actions were supposed to happen because of this do not happen leaving the system in an inconsistent state.
I don't believe this makes it synchronous. It's more that the transaction isn't complete until the event is sent.
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.
I would also suggest that this does not make it synchronous either as we are simply writing that the event happened. Not waiting for downstream systems to execute on the message.
I think that writing these messages on to the bus and ensuring that call succeeds is just as important now as ensuring the DB record is written.
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.
Synchronous was the wrong word, it's more like you'd be making the send of the message part of the "atomic block" of the flow.
Part of the goal of using an async event broker, though, is to move toward "eventual consistency", and force our services to adapt to inconsistent states. The ideal thing to do if kafka is down/unreachable/whatever isn't to fail the redemption flow; it's to have a mechanism for replaying events that occurred in a given time window, and to be able to rely on idempotent consumers to process those replayed events. Or to implement a dead-letter queue (here on the producer side).
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.
Now, having said all that, I should go through and check if this is already called from within a
transaction.atomic()
block.