Transactional outbox
I wrote another library in the "Make building reliable DOs easier" series.. this time it is to help create DO that use the Transactional Outbox pattern: https://github.com/evanderkoogh/do-transactional-outbox. Would love any feedback about how easy it is to setup and if you come across any edge-cases I haven't thought of..
5 Replies
Thank you so much for sharing this pattern. I'm not entirely sure why I'd use it, but I haven't heard about it before, and it's really nice to see DO code examples.
Btw, I opened a PR to fix something I caught in an initial scan https://github.com/evanderkoogh/do-transactional-outbox/pull/1/files
I'm stuck re-reading the full example in the README.md, but I'm just not seeing the bigger picture. Is there any chance you might add comments to the example which can point out why using
.put
in this context is interesting?
Ahh.. those are super good comments! Thanks for that
So basically the challenge you sometimes have is that you want to save something to a database and tell someone that you updates something.
So what you want is that either both the save and the sending happen, or neither happen.
With this library, this is what happens. (Assuming you are able to send messages at all). It handles things like saving both state and messages and automatically retries sending the messages.
Would that be applied for something like an operational transformation oriented collab architecture?
Then, making sure the actual messages are idempotent for the receiver (as I understand the referenced write up)
I am not entirely sure what you mean with an operational transformation oriented collab architecture, but yes, you want your messages to be idempotent for the receiver, because there is always the option you will get a message multiple times (at least once guarantee)