Anyone can build an integration that works when everything goes right. You connect two systems, you send a request, you get a clean reply, and the demo dazzles. But that’s not the job. The job is what happens at 2 a.m. when the network hiccups, the other system is mid-restart, and a request hangs in the dark. The real craft of integration is not making it work — it’s making it survive failure. Let me show you the mindset and the tools that get you there.
Assume failure — it’s not pessimism, it’s design
I tell every developer I mentor the same thing: assume failure. Networks drop. Systems go down. Timeouts happen. These aren’t rare disasters you can wave away — at scale they’re a daily fact of life. So you don’t design for the happy path and hope. You design for the unhappy path on purpose, because that’s the path that decides whether your integration is trustworthy.
Everything that follows is just the practical shape of that one belief.
Timeouts: decide how long you’ll wait
When you call another system, it might not answer. Maybe it’s busy, maybe the network swallowed your request. Without a timeout, your process waits forever, holding resources hostage. So you set a limit: “I’ll wait this long, and no longer.” A timeout isn’t giving up — it’s reclaiming control so you can decide what to do next instead of hanging indefinitely.
Retries: try again, but thoughtfully
Many failures are temporary. The system was busy for a second; the network blinked. So you retry. But retry carelessly and you make things worse — hammering a struggling system the instant it fails only kicks it while it’s down. The thoughtful pattern is to wait a little longer between each attempt, an approach called backoff. Try, wait a moment, try again, wait a bit more. Give the other side room to breathe.
A retry without backoff is a stampede. Give the failing system space, and far more of your problems quietly resolve themselves.
Idempotency: the safety net under retries
Here’s the trap. You send an order. The other system receives it and creates it — but the network drops before the confirmation reaches you. You don’t know it succeeded, so you retry. Now the order exists twice. You meant to be careful and you double-charged a customer.
The cure is idempotency: designing requests so that doing the same one twice has the same effect as doing it once. You attach a unique key to the request, and the receiving system remembers “I’ve already handled that key” and ignores the duplicate. This is the same idea I lean on when connecting to payment systems like Stripe — it’s what lets you retry boldly without fear of doubling the work. Idempotency is what makes retries safe. Without it, retries are a loaded gun.
Dead-letter queues: somewhere for the failures to wait
Sometimes a message fails and keeps failing — bad data, a system that stays down. You don’t want to retry forever, and you absolutely don’t want to silently drop it. So you set it aside in a dead-letter queue: a holding area for messages that couldn’t be processed. Nothing is lost. A human can review what landed there, fix the cause, and replay it. The worst outcome in integration is a message that vanishes with no trace. A dead-letter queue guarantees that never happens.
Logging and alerting: you can’t fix what you can’t see
All of this is useless if you’re blind to it. So you log — record what you sent, what came back, what failed and why. And you alert — when failures cross a threshold, something tells a human now, not next week when a customer complains. Logging is the black box that explains what went wrong after the fact; alerting is the smoke detector that wakes you before the fire spreads. Build both from day one, not after your first outage.
The craft is in the catch
Notice that none of this is about the request itself. The request is the easy part. The craft — the part that separates a hobbyist from a professional — is everything around the request: the timeout that reclaims control, the retry that’s patient, the idempotency key that makes it safe, the queue that catches the failures, the logs and alerts that keep you honest. Graceful failure handling is the engineering. A junior builds the happy path. A senior builds the recovery.
Master this, and you’ll build integrations that people trust — because they keep working on the worst night of the year, which is exactly the night that counts.
Your next step
See these ideas in a real connection with Connecting Salesforce to Stripe, where idempotency really earns its keep. Ground the bigger picture with Salesforce Integration for Beginners, and revisit the assume-failure mindset across systems in Connecting Salesforce to SAP. The full journey lives in the Integration category.