In logistics the interesting work is rarely the happy path. It is the nightly file that arrives at 03:12 with one malformed row, the warehouse system whose "API" is a folder on an FTP server, the scanner firmware that sends the same event twice when the signal drops in the far aisle. An integration is judged on how it behaves then.
Treat every message as if it will arrive twice
Delivery guarantees in the field are "at least once", whatever the documentation says. We give every inbound event a stable key and make processing idempotent, so a replay is boring instead of a duplicate shipment. This single decision removes a whole category of 2 a.m. phone calls.
- A stable key on every inbound event, taken from the sender where possible
- Processing that can be run twice with the same result
- A record of what was already handled, kept long enough to matter
Delivery guarantees in the field are "at least once", whatever the documentation says.
Keep the raw payload, forever
We store what the other side actually sent, untouched, next to what we made of it. When a partner changes a field without telling anyone — and they will — the difference between a two-hour fix and a two-week argument is having the original bytes. It also lets us re-run a day of traffic against corrected logic instead of asking for a re-send.
Make the mapping visible to the people who know the business
Status codes, depot identifiers and service levels are business knowledge, not engineering trivia. When the mapping lives in a screen the operations team can read, questions get answered without a developer. When it lives in a constant in the code, every tiny change becomes a release.
Alert on silence, not only on errors
The failure that hurts most is the feed that simply stops. We monitor expected volume per window, so a quiet channel raises an alarm the same way a failing one does. A pipeline that cannot tell you it is idle is a pipeline you will be told about by a customer.
