Home
Backend from First Principles / Module 17 — Graceful Shutdown

Graceful Shutdown

SIGTERM. Liveness vs readiness. Zero-downtime deploys in Kubernetes.


Why Graceful Shutdown Matters

When you deploy new code, the old server process receives a SIGTERM signal and needs to stop. If it stops immediately:
• In-flight requests are cut off → users get connection errors
• Jobs being processed are abandoned → data corruption
• DB connections aren't closed cleanly → connection leaks

Graceful shutdown means: "I got the signal. I'll finish what I'm doing, refuse new work, and then stop cleanly."

This is critical in Kubernetes (rolling deploys) and any cloud environment where containers are frequently restarted.


Implementation

JavaScript
process.on("SIGTERM", async () => {
  console.log("SIGTERM received. Starting graceful shutdown...");

  // 1. Stop accepting new connections
  server.close(() => {
    console.log("HTTP server closed");
  });

  // 2. Wait for in-flight requests to complete (with timeout)
  await waitForInflightRequests(30_000); // 30 second max

  // 3. Flush any pending logs/metrics
  await logger.flush();

  // 4. Close database connections
  await db.pool.end();

  // 5. Close Redis connections
  await redis.quit();

  // 6. Close message queue connections
  await queue.close();

  console.log("Shutdown complete");
  process.exit(0);
});

Kubernetes: Set terminationGracePeriodSeconds to match your timeout. Send SIGTERM, wait, then SIGKILL.


Health Checks

Kubernetes (and load balancers) use health checks to know if your service is ready to receive traffic.

Snippet
Liveness probe — Is the process alive? If not: restart the container.
  GET /health/live → 200 OK (as long as process is running)
Snippet
Readiness probe — Is the service ready to serve traffic? If not: remove from load balancer rotation.
  GET /health/ready → 200 OK (only if DB + Redis connections are healthy)
Snippet
During graceful shutdown:
  1. Mark readiness probe as UNHEALTHY immediately
  2. Load balancer stops sending new traffic
  3. Finish in-flight requests
  4. Shut down

This sequence ensures zero dropped requests during deploys.


Source & Credit

The Backend from First Principles series is based on what I learnt from Sriniously's YouTube playlist — a thoughtful, framework-agnostic walk through backend engineering. If this material helped you, please go check the original out: youtube.com/@Sriniously. The notes here are my own restatement for revisiting later.

⁂ Back to all modules