HTTP Request Lifecycle in Backend

What happens between calling fetch and the promise resolving on a cold connection?

The browser parses the URL, resolves the hostname through DNS, opens a TCP connection with a three-way handshake, negotiates TLS (one round trip for 1.3), sends the request line and headers, waits for the server to process the request, and resolves the promise as soon as the response status and headers have arrived. The body is read afterwards through a separate promise such as res.json().

Why does an await inside an Express handler not block other requests?

The await suspends only that handler's function. The database driver has written the query to a socket and registered a callback; control returns to the event loop, which keeps accepting and serving other connections. When the reply arrives, the promise resolves and the handler continuation runs as a microtask. Only synchronous CPU work blocks the loop.

app.get('/products/:id', async (req, res) => {
  // Suspends this handler only; the event loop stays free.
  const product = await db.query(
    'SELECT * FROM products WHERE id = $1',
    [req.params.id],
  );
  res.status(200).json(product);
});

What is the difference between a 401 and a 403, and between a 301 and a 302?

401 Unauthorized means the request lacks valid credentials and should include a WWW-Authenticate header telling the client how to retry. 403 Forbidden means the credentials were fine but the action is not allowed. 301 Moved Permanently tells clients the resource has a new address and may be cached, so future requests skip the old URL. 302 Found is temporary and must not be cached; 307 and 308 are the variants that guarantee the method and body are preserved on the follow-up request.

How does Express route an error to the error-handling middleware?

Calling next(err) with an argument tells Express to skip every remaining normal middleware and route handler and jump to the first middleware declared with four parameters (err, req, res, next). That handler logs the error and sends a response, usually a generic 500 so internal details never reach the client. In Express 5 a rejected promise from an async handler is forwarded to next automatically.

app.get('/products/:id', async (req, res, next) => {
  try {
    const product = await db.findProduct(req.params.id);
    if (!product) return res.status(404).json({ error: 'Not found' });
    res.json(product);
  } catch (err) {
    next(err); // jumps to the 4-arity handler below
  }
});

app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: 'Internal Server Error' });
});

What does keep-alive change about the cost of a second request, and how does HTTP/2 go further?

With keep-alive the TCP and TLS session stay open after the first response, so a second request to the same host skips DNS, the TCP handshake, and the TLS handshake and pays only one round trip plus server time. HTTP/2 multiplexes many requests as interleaved streams over that single connection, removing head-of-line blocking at the HTTP layer and the need for six parallel connections per host.