Q: What does “timeout” mean for a network request? A: Timeout refers to the limits you set for different stages of a request: connection timeout is how long you wait to open the TCP/TLS connection, read timeout is how long you wait for a response after the request is sent, and write timeout is how long you wait to send the request body. Use separate values, and a short connect timeout with a moderate read timeout is often best. Q: When should I increase timeout for third-party requests? A: Before you increase timeout for third-party requests, check whether the call is user-critical and whether cached or partial data can be used as a fallback. Also examine your p95/p99 latency and the partner’s SLA, and avoid raising timeouts across the board unless slow tails justify it. Q: How do I pick a data-driven timeout target when I decide to increase timeout for third-party requests? A: Gather a week of latency histograms (p50, p90, p95, p99), define a user-facing budget for the action, and set timeouts so that p95 fits comfortably with a small margin for p99 but never exceed the user budget. For example, if p95 is 700 ms and p99 is 1,400 ms, test a read timeout of 1,500–2,000 ms only if the page budget allows it. Q: How should I stage a rollout after changing timeouts? A: Start in non-prod with traffic replay or synthetic checks, then roll out to a small percentage of users (for example 5%) while watching errors, resource saturation, and thread/connection pools. Increase in steps (5% → 25% → 50% → 100%) with clear rollback rules and monitoring at each stage. Q: What retry strategy should I use to avoid extending user waits when I increase timeouts? A: Use exponential backoff with jitter and retry only idempotent methods, avoiding POSTs unless you have idempotency keys, and apply a per-attempt timeout plus a total deadline. For example, use three attempts at 500 ms each within a 1,600 ms total cap to keep retries bounded. Q: How do circuit breakers, bulkheads, and queue limits protect my app after increasing timeouts? A: A circuit breaker trips when errors or timeouts spike and fast-fails for a short period while probing for recovery, preventing long waits from cascading. Bulkheads limit concurrent calls to the provider and queue limits bound wait times so your app does not run out of threads or sockets. Q: What metrics and logs should I observe after you increase timeout for third-party requests? A: Track success rate, error rate, timeout rate, and latency percentiles (p50, p90, p95, p99) as well as resource saturation metrics like thread pool and connection pool usage and cost signals. Tag logs with request IDs and timeout values, trace retries and backoff delays, and alert on rising p95/p99 rather than only on absolute failures. Q: What common pitfalls should I avoid when changing timeouts? A: Avoid setting infinite timeouts, stacking per-attempt timeouts so retries exceed the user budget, and mismatched timeouts across services that lead to wasted work. Also propagate cancellations, avoid blocking main threads, don’t raise timeouts to hide provider incidents, and coordinate with rate limits to prevent compounded throttling.