System Design & Production Engineering: the practice test

Tail latency compounds. If one page issues 50 backend calls and each has a 1 percent chance of being slow, the odds that the page avoids every slow call are about 60:40 against. So the customer's 'it is sometimes really slow' is the p99 talking, and the average is hiding it. This is also why you fix tails structurally (timeouts, hedging, isolating slow dependencies) rather than by tuning the mean. The other claims have grains of truth but miss the compounding argument, which is the one interviewers want.

A timeout tells you nothing about whether the first request executed: it may have charged and lost only the response. So safety cannot come from timing, routing, or asking the user, none of which resolve that ambiguity. The idempotency key does: the client attaches a unique key per logical operation, the server records it with the outcome, and any replay returns the recorded outcome without re-executing. It is the pattern behind every serious payment API, and the reason this site's own payment fulfilment is pinned by tests to run exactly once.