Timeout: Why Must Waiting Have a Boundary?

A timeout does not mean, “Once this period has passed, the remote operation must have failed.” It means the waiting side has decided in advance that if no usable result arrives by a certain point, it will stop waiting and move to another response. A payment request sent from a phone illustrates the problem. A network packet may be lost, the server may still be processing, or the payment may already have succeeded. The timeout establishes only that the caller did not receive a definite answer in time.

Waiting matters because it occupies attention, threads, connections and opportunities for later work. Without a boundary, one uncertainty can hold resources indefinitely. A timeout turns the open possibility that a reply might still arrive into a manageable decision point.

A timeout also differs from a deadline and a retry. A deadline sets the latest completion time for the whole task; a timeout often limits one wait within it; a retry is one possible action afterwards. Blind retries can duplicate a payment or worsen congestion, so they need constraints such as idempotence and backoff. The central point is that a timeout does not remove uncertainty. It limits the time and resources a system spends on it.

https://aws.amazon.com/builders-library/challenges-with-distributed-systems/
https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/