We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 9-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 Microservices Architecture
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”
In the , calling a function is guaranteed to work. The function is in the same process, same memory space. It either runs or your entire application is dead.
In , every function call that crosses a service boundary is a network call. And networks fail in ways that monolith developers never think about:
| Failure Mode | What Happens | Frequency |
|---|---|---|
| Packet loss | Your request or response gets dropped | Common under load |
| Timeout | Server is slow, your client gives up waiting | Very common |
| Connection refused | Server is overloaded and rejecting connections | Common during spikes |
| resolution failure | Can't find the service's IP | Rare but happens |
| reset | Connection dropped mid-request | Occasional |
Google's Maglev paper reports that even within their private data center network, packet loss rates hit 0.01% during normal operation and spike to 1-2% during network maintenance windows. At Google's scale of 1 billion+ requests per second, 0.01% means 100,000 dropped packets every second.
Most of these are transient. They fail once and succeed the next time. A dropped packet doesn't mean the server is down. A timeout doesn't mean the service is broken. It might just mean a garbage collection pause, a momentary network blip, or a rebalancing connections.
Retry logic turns these transient failures into invisible hiccups. Without retries, your users see errors. With retries, they never notice.
Retry logic is simple in concept: if a request fails, try again. The complexity is in the details.
What to retry:
What NOT to retry:
Retry configuration:
| Parameter | What It Controls | Typical Value |
|---|---|---|
| Max retries | How many times to retry before giving up | 2-5 |
| Retry delay | How long to wait between retries | 100ms-1s |
| Retryable errors | Which error codes trigger a retry | 5xx, timeout, connection errors |
| Timeout per attempt | How long to wait for each individual attempt | 1-5 seconds |
AWS SDK defaults: 3 retries with exponential backoff starting at 100ms. defaults: no automatic retries (you configure a retry policy per method). Stripe's API client retries network errors twice with exponential backoff, starting at 500ms.