Zero-downtime deployment concept in Express - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create an Express server that listens on port 3000.

Express

const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('Hello World!'));
app.listen([1], () => console.log('Server running'));

Drag options to blanks, or click blank then click option'

A3000

B80

C5000

D8080

Attempts:

3 left

💡 Hint

Common Mistakes

Using port 80 without permissions

Using an undefined port variable

The server listens on port 3000, which is a common default for Express apps.

2fill in blank

medium

Complete the code to gracefully close the server on shutdown.

Express

const server = app.listen(3000);
process.on('SIGTERM', () => {
  server.[1](() => {
    console.log('Server closed');
  });
});

Drag options to blanks, or click blank then click option'

Aclose

Bstop

Cshutdown

Dend

Attempts:

3 left

💡 Hint

Common Mistakes

Using non-existent methods like stop or shutdown

Calling end which is for streams

The close method stops the server from accepting new connections and waits for existing connections to finish.

3fill in blank

hard

Fix the error in the code to handle new connections during zero-downtime deployment.

Express

const http = require('http');
const server = http.createServer(app);
server.listen(3000);
server.on('connection', (socket) => {
  socket.[1] = false;
});

Drag options to blanks, or click blank then click option'

Aclose

Bdestroy

Cclosed

Ddestroyed

Attempts:

3 left

💡 Hint

Common Mistakes

Using methods instead of properties

Confusing 'close' event with property

The destroyed property indicates if the socket is destroyed. Setting it to false means the socket is active.

4fill in blank

hard

Fill both blanks to track active connections and close them on shutdown.

Express

const connections = new Set();
server.on('connection', (socket) => {
  connections.[1](socket);
  socket.on('close', () => connections.[2](socket));
});

Drag options to blanks, or click blank then click option'

Aadd

Bremove

Cdelete

Dpush

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'push' on a Set

Using 'remove' which is not a Set method

Use add to add sockets to the set and delete to remove them when closed.

5fill in blank

hard

Fill all three blanks to close all active connections during server shutdown.

Express

process.on('SIGTERM', () => {
  server.[1](() => console.log('Server closed'));
  for (const socket of connections) {
    socket.[2]();
    connections.[3](socket);
  }
});

Drag options to blanks, or click blank then click option'

Aclose

Bdestroy

Cdelete

Dstop

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'stop' which does not exist

Using 'close' on sockets instead of 'destroy'

Call close on the server, destroy on each socket to close it, and delete to remove the socket from the set.

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