Connect to anything you do not run and you have taken on its bad days as well as its good ones. It will time out, it will return an error you have never seen, it will be slow at exactly the hour your traffic peaks, and once in a while it will answer confidently with something wrong.
None of that is unusual. What differs between systems is whether somebody thought about it in advance.
Decide what the failure means
The first question is not technical. It is: if this call fails, what should the business do?
Sometimes the answer is stop. If a payment cannot be authorised, the order must not proceed, and the customer needs to be told plainly.
Often the answer is carry on. If the courier’s rate service is down, the order can still be taken with a fallback rate. If the accounting system is unreachable, the invoice can be issued and the sync can wait.
These are different behaviours, and the difference belongs to whoever owns the business, not to whoever writes the code. Getting the answer in advance is most of the work.
Separate the errand from the request
Anything that can wait should not happen while a customer is looking at a loading spinner. Put it in a queue: the request records what needs to happen, and a separate worker does it, retries it, and gives up in a way somebody notices.
The retry needs to back off — a service that is struggling does not need your system hitting it every second — and it needs a limit. An unlimited retry against a permanent error is a machine repeating a mistake forever.
And the queue needs a dead end that is visible. A failed job nobody sees is worse than a failure the customer saw, because at least the customer would have told you.
Do not trust the happy path you tested
The hardest failures are the ambiguous ones: the request timed out, so you do not know whether it was received. That is why the previous rules matter — everything you send should be identified in a way that lets you ask “did this one arrive?” rather than guessing, and everything you receive should be safe to receive twice.
Timeouts are not an edge case. They are the normal operating condition of a network you do not own.