Server architecture basics: what actually happens between DNS and your code

What happens between the click and your code?

1. 1DNS resolution turns the hostname into an IP — cached, but a cold lookup can cost 20–120ms.
2. 2TCP connection and TLS handshake — one to two round trips, less with TLS 1.3 and session resumption.
3. 3The CDN edge answers if the resource is cached; otherwise it forwards to the origin, often over a warm connection.
4. 4A load balancer selects a healthy instance.
5. 5A reverse proxy terminates TLS, applies headers, compresses, and may serve static files directly.
6. 6Your application server runs the handler.
7. 7The handler queries a database or cache, each with its own connection and latency.
8. 8The response travels back, is compressed and cached according to your headers.

Every one of those steps is measurable. Server-Timing headers let you attribute time to each phase and see it in the browser's network panel — the fastest way to stop guessing.

What does each component do?

Where do connections become the bottleneck?

At the database, almost always, because each application instance holds a pool and instances multiply.

Ten application containers with a pool of 20 connections each means 200 connections to a database configured for 100. Under autoscaling this fails at exactly the moment traffic is highest. A connection pooler in front of the database — PgBouncer or a managed equivalent — decouples application scaling from database connection limits.

• Size pools deliberately: (instances × pool size) must stay under the database limit with headroom.
• Serverless functions need a pooler or a data proxy; each invocation otherwise wants its own connection.
• Set connection and statement timeouts so one stuck query cannot hold a connection forever.
• Monitor pool wait time — requests queueing for a connection look identical to a slow database from the outside.

How should health checks be designed?

// Liveness: is the process alive? Keep it trivial.
app.get("/healthz", (_, res) => res.status(200).send("ok"));

// Readiness: can this instance serve traffic right now?
app.get("/readyz", async (_, res) => {
  const checks = await Promise.allSettled([db.ping(), cache.ping()]);
  const ok = checks.every((c) => c.status === "fulfilled");
  res.status(ok ? 200 : 503).json({ ok, checks: checks.map((c) => c.status) });
});

How do you decide what to scale?

1. 1Measure first: is the time in the network, the app, or the database? Distributed tracing answers this in minutes.
2. 2Cache before scaling. A correct cache header on a static asset beats another server.
3. 3Scale stateless application instances horizontally; it is the easy axis.
4. 4Scale the database last and carefully — read replicas for read-heavy load, partitioning only when genuinely needed.
5. 5Remove work: an N+1 query fixed is worth more than a doubled instance count.