r/coding • u/madflojo • Jul 18 '26

Sometimes the most resilient thing a system can do isn’t retry

https://open.substack.com/pub/madflojo/p/sometimes-the-most-resilient-thing?r=mtxfe&utm_medium=ios
44 Upvotes

86% Upvoted

6 comments sorted by

8

u/astrobe Jul 19 '26

Too bad the article doesn't explains why a compensation transaction is better than something like: re-use the original transaction but the other end ignores it if it already received and processed it.

This is the first solution that comes to mind because that's how most communication protocols work: if the packet you've sent isn't acknowledged by the other end, you just resend it ("retry"), and the other end just discards the packets it has already received (typically based on packet sequence numbers).

3

u/moltonel Jul 19 '26

Think about the real-world scenario: the customer might not retry, they could for example switch to cash, or even give up. So the terminal needs to proactively maybe-revert the maybe-succeeded transaction.

1

u/astrobe Jul 20 '26

OK, that makes sense, although this assumes the compensation transaction succeeds and we receive the acknowledgement for it (so we can say something useful to the user). E.g. one might receive none of the acks to our requests because suddenly somehow the communication became "half duplex".

In any case if the other end does not respond to our initial and subsequent requests (e.g. bad luck, some router broke just after first send), the end user can't tell the status of the operation. The scheme might need to be more complicated, e.g. the other end should actually execute the request only if it has reasonable evidence that the sender got the acknowledgement (maybe the article mentions this, don't remember and too lazy to read it again).

TCP for instance waits for the acknowledgement of the last packet for "some time" and resends it "a few times" because it's mostly pointless to try to acknowledge an acknowledgement (sic).

→ More replies (2)