BackendPrep
All Guides/APIs & Protocols/API Timeouts, Retries and Failure Handling
Distributed ResilienceAPIs & ProtocolsIntermediate15 min read

API Timeouts, Retries and Failure Handling

How to prevent cascading failures in distributed backend services — master Connect vs Read timeouts, Exponential Backoff with Full Jitter, avoiding the catastrophic Retry Storm, and implementing Circuit Breakers.

Technologies:ReliabilityDistributed SystemsAPIsResilience
Foundational Principles vs Practical Heuristics
Universal Principle (Inviolable Truth):

Every network call must have an explicit, bounded timeout. An unbounded network socket call will hold operating system threads and connection pool sockets open indefinitely, leading to complete thread starvation.

Practical Heuristic (Rule of Thumb):

Always add random jitter to exponential backoff retries. Without jitter, synchronized retry spikes from thousands of failed clients hit the recovering downstream service in waves, immediately knocking it back offline.

Production Illustrative Example:If 10,000 mobile clients all experience a timeout and retry with fixed backoff of 2 seconds, the recovering database gets hammered with 10,000 synchronized queries at $t=2s$, $t=4s$, and $t=6s$, preventing recovery.
Target Competencies & Learning Outcomes:
  • Distinguish between Connect Timeouts, Read Timeouts, and overall Request Deadlines
  • Understand why naive immediate retries trigger catastrophic Retry Storms on degraded services
  • Implement Exponential Backoff with Full Jitter using clean mathematical algorithms
  • Master Circuit Breaker state transitions (Closed, Open, Half-Open) to fail fast and protect worker pools

1. The Anatomy of a Timeout: Connect vs Read

Free Chapter Preview

Never configure a generic single "timeout" value without understanding the two distinct phases:

1. Connect Timeout (TCP Handshake)

  • The time allowed to establish the physical TCP connection and TLS handshake with the remote host.
  • Should be aggressive and short (e.g. 500ms - 2s). If a remote server cannot complete a TCP handshake in 1 second, it is either dead, unreachable, or suffering a network partition.

2. Read / Socket Timeout (I/O Duration)

  • The maximum time allowed between two consecutive data packets received from the remote server after the connection is established.
  • Should be calibrated to the expected p99 latency of the downstream query (e.g. 3s - 5s).

2. The Catastrophic Retry Storm

In this section, we examine the production failure mechanics, internal socket buffers, and kernel-level trace diagnostics...

100% Free Knowledge Library

Sign In to Read the Full Guide

Unlock all remaining 5 chapters of API Timeouts, Retries and Failure Handling. Get complete production code snippets, architectural trade-offs, and track your reading completion.

Explore Other Guides
✓ Free Google / GitHub Sign-In•✓ No Subscription Required•✓ Instant Access