We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 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 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 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”
A service can be running but not working. The process is alive, memory is allocated, the port is open, but it is stuck in a deadlock, overwhelmed by requests, or unable to reach its database. From the outside, it looks healthy. From the inside, it is a zombie.
Health checks distinguish between truly healthy services and zombie services. uses three types: liveness probes (is the process stuck?), readiness probes (can it accept traffic?), and startup probes (has it finished initializing?). Load balancers use health checks to route traffic away from unhealthy instances.
Getting health checks wrong is more common than you think. A liveness check that always returns 200 is useless. A liveness check that calls the database creates a cascading failure when the database is slow. A readiness check with too short a timeout flaps during load spikes, causing traffic oscillation.
| Check Type | Question It Answers | Failure Action | Example |
|---|---|---|---|
| Liveness | Is the process stuck/deadlocked? | Restart the container | GET /healthz returns 200 |
| Readiness | Can it accept traffic right now? | Remove from | Check DB connection pool |
| Startup | Has it finished initializing? | Wait (do not restart yet) | Migrations complete, cache warmed |
| Deep health | Are all dependencies accessible? | Alert, degrade gracefully | Check DB, cache, external APIs |
Critical anti-pattern: Do NOT check external dependencies in liveness probes. If the database is slow, your liveness probe times out, restarts your pod, the new pod also cannot reach the database, gets restarted, and you enter a restart loop. Liveness should only check the process itself. Use readiness probes for dependency checks.