Zero-downtime deployment concept in Express - Step-by-Step Execution

Concept Flow - Zero-downtime deployment concept

Start Current Server

↓

Deploy New Server Version

↓

New Server Listens on Same Port

↓

Redirect Incoming Requests to New Server

↓

Old Server Finishes Active Requests

↓

Old Server Shuts Down

↓

Deployment Complete - No Downtime

This flow shows how a new server version starts alongside the old one, takes over requests, and the old server closes only after finishing active work, ensuring no downtime.

Execution Sample

Express

const http = require('http');

// Old server
const oldServer = http.createServer((req, res) => {
  res.end('Old Server Response');
});
oldServer.listen(3000);

// New server starts
const newServer = http.createServer((req, res) => {
  res.end('New Server Response');
});
// New server listens on same port after old server closes
oldServer.close(() => {
  newServer.listen(3000);
});

This code shows two servers: old and new. The new server waits to listen until the old server finishes, to avoid downtime.

Execution Table

Step	Action	Old Server State	New Server State	Request Handling
1	Start old server listening on port 3000	Listening	Not started	Handled by old server
2	Deploy new server code	Listening	Not started	Handled by old server
3	New server attempts to listen on port 3000	Listening	Error (port busy)	Handled by old server
4	Send signal to old server to stop accepting new connections	Closing to new requests	Not started	Handled by old server
5	Old server finishes active requests	Closed	Not started	No requests handled
6	New server starts listening on port 3000	Closed	Listening	Handled by new server
7	All new requests handled by new server	Closed	Listening	Handled by new server
8	Old server fully shut down	Stopped	Listening	Handled by new server

💡 Old server stops and releases port; new server listens on port 3000; requests handled without downtime.

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 6	Final
oldServerState	Not started	Listening	Closed	Closed	Stopped
newServerState	Not started	Error (port busy)	Not started	Listening	Listening
requestHandling	None	Old server	None	New server	New server

Key Moments - 3 Insights

Why can't the new server listen on the same port while the old server is still running?

Because the port is already in use by the old server (see execution_table step 3), the new server gets an error until the old server releases it.

How does the old server avoid dropping active requests during deployment?

The old server stops accepting new requests but finishes active ones before closing (see execution_table steps 4 and 5), ensuring no requests are dropped.

When does the new server start handling requests?

Only after the old server fully closes and releases the port, the new server starts listening and handles all new requests (see execution_table step 6).

Visual Quiz - 3 Questions

Look at the execution table, at which step does the old server stop accepting new requests?

A Step 4

B Step 2

C Step 6

D Step 8

💡 Hint

Check the 'Old Server State' column for when it changes to 'Closing to new requests'.

According to the variable tracker, what is the new server state after step 3?

A Not started

B Error (port busy)

C Listening

D Closed

💡 Hint

Look at the 'newServerState' row under 'After Step 3' in the variable tracker.

If the old server did not finish active requests before closing, what would happen?

A New server would start earlier

B Old server would keep running forever

C Requests might be dropped causing downtime

D Port would be free immediately

💡 Hint

Refer to key moment about finishing active requests to avoid dropped requests.

Concept Snapshot

Zero-downtime deployment means running new server version alongside old one.
Old server stops accepting new requests but finishes active ones.
New server starts listening only after old server releases port.
This avoids downtime by smoothly switching servers.
Use signals or process managers to coordinate shutdown and startup.

Full Transcript

Zero-downtime deployment in express means updating your server without stopping service. First, the old server runs and handles requests. When deploying a new version, it tries to listen on the same port but can't because the old server is still using it. So, the old server stops accepting new requests but finishes any active ones. Once done, it closes and frees the port. Then the new server starts listening on that port and handles all new requests. This way, users never experience downtime during deployment.

Practice

1. What is the main goal of zero-downtime deployment in an Express app?

easy

A. Keep the app running without interruption during updates

B. Stop the app completely before updating

C. Restart the server manually after every update

D. Disable all routes temporarily during deployment

Solution

1. Step 1: Understand zero-downtime deployment purpose

   It aims to keep the app available and responsive while new code is deployed.

2. Step 2: Compare options with this goal

   Only keeping the app running without interruption matches zero-downtime deployment.

3. Final Answer:

   Keep the app running without interruption during updates -> Option A

4. Quick Check:

   Zero-downtime = no interruption [OK]

Hint: Zero downtime means no app stops during update [OK]

Common Mistakes:

• Thinking the app must stop to update
• Confusing manual restart with automatic update
• Assuming routes must be disabled during deployment

2. Which Node.js module helps run multiple instances of an Express app for zero-downtime deployment?

easy

A. http

B. path

C. fs

D. cluster

Solution

1. Step 1: Identify module for multiple app instances

   The cluster module allows running multiple worker processes of the app.

2. Step 2: Verify other modules' purposes

   http handles server requests, fs handles files, path handles file paths, none manage multiple processes.

3. Final Answer:

   cluster -> Option D

4. Quick Check:

   Multiple instances = cluster module [OK]

Hint: Cluster module manages multiple workers [OK]

Common Mistakes:

• Choosing http for multiple processes
• Confusing fs or path with process management
• Not knowing cluster exists

3. Given this code snippet using cluster in Express, what happens when a worker crashes?

const cluster = require('cluster');
const express = require('express');
if (cluster.isMaster) {
  cluster.fork();
  cluster.on('exit', (worker) => {
    console.log('Worker died, starting a new one');
    cluster.fork();
  });
} else {
  const app = express();
  app.get('/', (req, res) => res.send('Hello'));
  app.listen(3000);
}

medium

A. A new worker starts automatically

B. No new worker starts, app crashes

C. The app stops completely

D. The master process crashes

Solution

1. Step 1: Analyze cluster exit event handler

   When a worker exits, the master logs a message and forks a new worker.

2. Step 2: Understand effect on app availability

   Replacing crashed workers keeps the app running without downtime.

3. Final Answer:

   A new worker starts automatically -> Option A

4. Quick Check:

   Worker crash triggers new worker fork [OK]

Hint: cluster.on('exit') forks new worker on crash [OK]

Common Mistakes:

• Thinking app stops when worker dies
• Assuming master process crashes
• Missing automatic restart logic

4. Identify the error in this zero-downtime deployment code snippet:

const cluster = require('cluster');
const express = require('express');
if (cluster.isMaster) {
  cluster.fork();
  cluster.on('exit', () => {
    console.log('Worker died');
  });
} else {
  const app = express();
  app.listen(3000);
}

medium

A. Using cluster.isMaster instead of cluster.isWorker

B. Missing code to restart worker on exit

C. Express app should be created in master process

D. app.listen should be outside else block

Solution

1. Step 1: Check cluster exit event handler

   The exit event logs a message but does not fork a new worker.

2. Step 2: Understand impact on zero-downtime

   Without restarting workers, the app loses capacity and may cause downtime.

3. Final Answer:

   Missing code to restart worker on exit -> Option B

4. Quick Check:

   Exit handler must fork new worker [OK]

Hint: Restart workers on exit to avoid downtime [OK]

Common Mistakes:

• Not restarting workers after exit
• Confusing master and worker roles
• Placing app.listen in wrong process

5. You want to deploy a new version of your Express app without downtime. Which approach best achieves this?

1. Use cluster to run multiple workers
2. On update, fork new workers with new code
3. Gracefully disconnect old workers after new ones are ready
4. Restart the entire server process immediately

Which steps should you follow?

hard

A. Steps 1 and 4 only

B. Only step 4

C. Steps 1, 2, and 3

D. Steps 2 and 4 only

Solution

1. Step 1: Understand zero-downtime deployment best practices

   Running multiple workers (step 1) allows traffic to continue during updates.

2. Step 2: Deploy new code by forking new workers (step 2) and gracefully disconnect old ones (step 3)

   This ensures no requests are dropped and old workers finish their tasks.

3. Step 3: Avoid immediate server restart (step 4) as it causes downtime

   Restarting the whole server stops all workers at once, causing downtime.

4. Final Answer:

   Steps 1, 2, and 3 -> Option C

5. Quick Check:

   Fork new workers and gracefully disconnect old [OK]

Hint: Fork new workers before disconnecting old ones [OK]

Common Mistakes:

• Restarting server immediately causing downtime
• Not gracefully disconnecting old workers
• Skipping multiple worker setup