5 ms·
Easy exactly-once delivery: Send a transaction ID with the transaction using an at-least-once system. The receiver ignores duplicate ID transactions. The sender
by dheera 2y ago
Easy exactly-once delivery: Send a transaction ID with the transaction using an at-least-once system. The receiver ignores duplicate ID transactions. The sender can guarantee never sending the same ID twice.
- magicalhippo 2y agoBut then it's not the transport system that provides exactly-once delivery, but rather the users of the system.
- dheera 2y agoWrap that up and abstract it as a transport system. The users don't need to know the inner workings, they just need a transport API that guarantees exactly-once.
- magicalhippo 2y agoThe point is you can't wrap that up, because the faults can happen at the edges, ie where the systems interact. The users still need to interact with this wrapped system, and it's those interactions that can fail, thus preventing the overall exactly-once delivery. To flip it around, if this wasn't an issue then what you're suggesting already exists in the form of ACID databases.
- orf 2y ago> they just need a transport API that guarantees exactly-once Which is the same problem, but at a different layer.
- Maxatar 2y agoThat's what the article calls exactly once processing. An analogy would be pizza delivery. You wouldn't call someone who delivered 100 identical pizzas to you even though you only ate one of them "exactly once delivery".
- kelnos 2y agoAgreed, if I had to be the one who dealt with the extra pizzas. But if there was someone standing outside in my yard in order to discard the 99 duplicate pizzas before they got to my door (a travesty in and of itself, but that's another discussion), I would think of the system as a whole as "exactly once delivery". And, analogously, that does seem to be what Sequin's system provides.
- Maxatar 2y agoBut that wouldn't work which is the problem. If someone named Bob was standing outside your yard discarding the 99 pizzas, then Bob would not be able to guarantee that you actually get exactly one pizza. It's possible that the one pizza Bob tries to give you gets rained on before Bob can actually hand it to you. Only you yourself can actually implement a means of discarding extraneous pizzas, any middlemen introduced into the chain just adds another layer of indirection that is susceptible to failure.
- avmich 2y agoNo, Bob standing outside of your yard is principally closer to you - as in, holding your hand - and can't fail to release pizza only after you got hold of it. Of course the rain may flip bits in any system, but that would amount to destruction of you. You won't worry about pizza then, but your clone will spring up and get the pizza from Bob. And Bob himself is similarly protected from single-point-of-failure problems. Of course the whole Bob subsystem may be destroyed, but that's already beyond the threshold of the problem we choose. Otherwise we'd have the external system to check if we'd actually got the pizza, and resend it again. EDIT: that's probably the definition of "only you" - the Bob being that close. Agree then.
- Maxatar 2y agoIf you have a system where failure is impossible then none of this applies and yes, you can implement a deliver exactly once protocol. It's only in systems where failure is a possibility that exactly once delivery becomes impossible.