We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
5 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
The default connect timeout on Linux is 127 seconds. The default HTTP client timeout in Java's HttpClient is infinite. Go's net/http read timeout? Also infinite.
Every network call your system makes is a bet that the other side will answer. Without an explicit timeout, your code will wait forever for a response that may never arrive. One slow database query holds a thread. Ten slow queries hold ten threads. A hundred slow queries exhaust the connection pool, and suddenly your healthy service is dead because it trusted a default that no production system should ever ship with.
Netflix learned this the hard way before Hystrix. A single slow recommendation service consumed every thread in the edge gateway, blocking all traffic including the perfectly healthy login and playback paths. The fix was simple: a 1 second timeout on every external call. That single number prevented more outages than any other configuration change in Netflix's history, according to their engineering blog from 2012.
Timeouts are the most basic reliability pattern and the most commonly misconfigured. This lesson covers the full timeout stack, from TCP connect through deadline propagation across service boundaries.
Every network request passes through multiple timeout layers, and each one has its own default. If you only set one and ignore the others, the one you missed becomes the real timeout.
| Layer | What It Controls | Common Default | What You Should Set |
|---|---|---|---|
| connect | Time to establish the socket | 127s (Linux), infinite (Java) | 1-3 seconds |
| TLS handshake | Time to complete cryptographic negotiation | Often same as connect | 2-5 seconds |
| Socket read | Maximum time between bytes arriving | Infinite in most languages | 5-15 seconds |
| Request total | Maximum time for the entire operation | Varies wildly | Your SLO minus slack |
The cardinal rule is that inner timeouts must be strictly shorter than outer timeouts. If your client timeout is 30 seconds but your database driver timeout is 60 seconds, the database driver keeps running its query after the HTTP client has already given up. The client returns an error to the user, but the database connection stays occupied by a query whose result will be thrown away. This is wasted work, and it is the primary cause of thread pool exhaustion during cascading overloads.
Netflix Hystrix defaulted every call to 1 second. Google SRE book recommends 2 seconds as the upper bound for user-facing requests. Stripe uses 80 seconds for webhook delivery because merchant backends need time for database writes. The right number depends on your SLO, not on what ships out of the box.