We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
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 Devops Cicd
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 financial trading platform went down for 30 seconds during a deployment. In those 30 seconds, pending trades could not execute, market data stopped flowing, and clients missed trading opportunities. The company received $50,000 in claims from clients who lost money during the outage. A 30-second deployment window that seemed harmless cost real money.
Zero-downtime deployment ensures users never experience unavailability during deployments. Not "almost zero." Actually zero. Every request during the deployment window receives a response from either the old or new version. No 502s, no connection resets, no timeouts.
This is not a single technique. It is a set of requirements that your deployment strategy (rolling, blue-green, canary) must satisfy. You can have a rolling deployment with downtime (if you skip health checks) or a rolling deployment with zero downtime (if you get every detail right).
Every zero-downtime deployment needs all five of these. Miss one, and users see errors.
| Requirement | What It Means | What Happens If You Skip It |
|---|---|---|
| Health checks | New instances proven healthy before receiving traffic | Traffic hits pods that are not ready, users get 503s |
| Graceful shutdown | Old instances finish in-flight requests before terminating | Active requests are killed mid-response, users get connection resets |
| Connection draining | stops sending new requests to dying pods | New requests land on a pod that is about to terminate |
| Backward compatibility | Old and new versions coexist during the transition | Requests get inconsistent responses depending on which version handles them |
| Database compatibility | Schema changes work with both old and new app versions | Old version crashes when it reads a column that was renamed or dropped |
Graceful shutdown sequence in detail:
If your application does not handle SIGTERM (many frameworks do not by default), the orchestrator sends SIGKILL after the grace period. SIGKILL cannot be caught. Every in-flight request is terminated immediately.
-specific settings that affect zero downtime:
| Setting | Default | Recommended |
|---|---|---|
terminationGracePeriodSeconds | 30s | Match your longest request + buffer |
preStop lifecycle hook | None | sleep 5 to let endpoints propagate |
| Readiness probe | None | GET on /health, 5s interval |
minReadySeconds | 0 | 30-60s (wait before marking ready) |
The preStop: sleep 5 is a common trick. When Kubernetes marks a pod for termination, the endpoint removal propagates asynchronously to all kube- instances and ingress controllers. Without the sleep, the pod starts shutting down before all load balancers have stopped sending it traffic.