0
0
Expressframework~10 mins

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

Choose your learning style9 modes available
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
StepActionOld Server StateNew Server StateRequest Handling
1Start old server listening on port 3000ListeningNot startedHandled by old server
2Deploy new server codeListeningNot startedHandled by old server
3New server attempts to listen on port 3000ListeningError (port busy)Handled by old server
4Send signal to old server to stop accepting new connectionsClosing to new requestsNot startedHandled by old server
5Old server finishes active requestsClosedNot startedNo requests handled
6New server starts listening on port 3000ClosedListeningHandled by new server
7All new requests handled by new serverClosedListeningHandled by new server
8Old server fully shut downStoppedListeningHandled by new server
💡 Old server stops and releases port; new server listens on port 3000; requests handled without downtime.
Variable Tracker
VariableStartAfter Step 3After Step 5After Step 6Final
oldServerStateNot startedListeningClosedClosedStopped
newServerStateNot startedError (port busy)Not startedListeningListening
requestHandlingNoneOld serverNoneNew serverNew 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
Test your understanding
Look at the execution table, at which step does the old server stop accepting new requests?
AStep 4
BStep 2
CStep 6
DStep 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?
ANot started
BError (port busy)
CListening
DClosed
💡 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?
ANew server would start earlier
BOld server would keep running forever
CRequests might be dropped causing downtime
DPort 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.