The Lost Message
Two lifelines, an arrow, and a red X halfway across. Then the only question that matters: what does each side believe now? Every retry bug, every duplicate payment and every orphaned record lives in the gap between those two beliefs.
Your system sends a payment instruction to the bank. The request goes out. Then nothing — the connection times out before any reply arrives. What should your system do next?
Click any arrow to lose it in transit. Keyboard: tab to an arrow and press Enter.
The double charge
A timeout treated as a failure, plus a retry, plus a non-idempotent endpoint, equals a customer charged twice. Every one of those three decisions looked correct on its own, and the fix is one field on the request.
The silent one
A lost callback leaves one side waiting forever and the other side finished. Nothing alerts, nothing errors, and a number quietly goes wrong on a dashboard somebody is making decisions from. Silent failures are worse than loud ones precisely because nothing is broken.
It is not just software
You email a supplier to cancel an order and hear nothing. Did it arrive? Same grammar exactly: two parties, a lost message, and two people confidently holding different beliefs about the same fact.
Make the second one harmless
You cannot stop messages being lost. You can make a repeat safe: an idempotency key turns "did it arrive?" into a question you no longer need to answer, because sending twice does the same thing as sending once.
You cannot stop messages going missing, and you cannot tell a lost request from a lost reply. What you can do is make the second delivery harmless — which turns "did it arrive?" from a question you must answer into one you no longer need to. Before you ship an integration, put a red X on every arrow in turn and write down what each side believes. The dangerous failures are never where the alerting is.