Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why does zero-downtime deployment fundamentally depend on graceful shutdown being correctly implemented, regardless of which specific deployment strategy (rolling, blue-green) is used?
💻 Code Challenge | +75 XP
Implement a graceful shutdown handler that stops accepting new connections on SIGTERM while allowing in-flight requests to complete, and design a rolling deployment sequence (as pseudocode) that gates progression to the next instance on a confirmed health check.
A rolling deployment caused a brief spike in failed requests, traced to instances being terminated without finishing requests that were already in progress at the moment of shutdown. Reorder the steps to fix this using proper graceful shutdown.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Deploying a new version without implementing graceful shutdown in the application itself
// Wrong: abrupt termination drops in-flight requests
process.on("SIGTERM", () => process.exit(0));
// Correct: finishes in-flight work before exiting
process.on("SIGTERM", async () => {
await server.close(() => process.exit(0));
});The Solution //
Regardless of how sophisticated the overall deployment strategy is (rolling, blue-green), if an individual instance is abruptly terminated without first stopping new connections and allowing in-flight requests to complete, any request that happened to be in progress at that exact moment is dropped — undermining the zero-downtime goal at the level of individual instance termination.
The Error //
Running a destructive database migration (dropping a column, renaming a table) alongside a rolling deployment
// Unsafe during a rolling deploy: old code may still reference this
ALTER TABLE users DROP COLUMN legacy_field;
// Safer: additive change, backward-compatible with both versions
ALTER TABLE users ADD COLUMN new_field VARCHAR(50);
// Remove the old column in a LATER, separate deploy, once old code is fully retiredThe Solution //
During a rolling deployment, old and new versions of the application code run simultaneously against the same database for the duration of the rollout — a destructive migration that the still-running old code depends on can cause the old instances to start failing immediately, before the rollout even completes.