2. From code to an internet request

A deployment stops feeling mysterious when you follow one request. Every layer has one handoff to make and one category of failure to own.

One request through production

GET https://api.example.com/articles
              │
              ▼
        DNS finds an address
              │
              ▼
     HTTPS establishes a secure connection
              │
              ▼
 reverse proxy or load balancer accepts traffic
              │
              ▼
     application process on an internal port
              │
              ▼
       database / cache / upstream API
              │
              ▼
          JSON response returns

Code becomes a process

A Python file on disk is inert. It becomes useful when an operating system starts an interpreter and creates a process. For a web application, that process might be Gunicorn starting Flask workers or Uvicorn starting a FastAPI application. The process consumes memory and CPU, writes logs, receives signals, and can crash.

The process listens on a port. A port is not a server and it is not a URL; it is a numbered entry point on a machine. Your local app might listen on port 8000. In production, that port is usually private. A public-facing component accepts traffic on the standard HTTPS port and forwards it to the application's internal port.

A domain is an address book entry

DNS translates api.example.com into an address a client can connect to. HTTPS then authenticates the server and encrypts the connection. A reverse proxy or load balancer terminates that connection, checks which hostname or path was requested, and routes the request to a healthy application instance.

These layers explain why "the server is down" is rarely a complete diagnosis. DNS can point at the wrong destination while the app is healthy. A certificate can expire while the process keeps running. A load balancer can reject an instance because its health endpoint fails. The Python route may answer correctly from inside the machine while no public request can reach it.

The process still needs supervision

Starting a process manually is not a production strategy. Something must start it after a reboot, restart it after a crash, supply its configuration, capture its output, and decide when it is healthy enough to receive traffic. A managed platform handles most of that. On a virtual machine, a service manager and reverse proxy may handle it. A container platform expresses the same responsibilities around containers.

The durable mental model

A container does not replace the process. It provides an isolated environment in which that process runs. A platform does not replace the container. It decides where and how to start it.

Check your understanding

Your API works at localhost:8000 on a server, but its public domain times out. Which layers would you check before changing Python code?

Check DNS, firewall rules, the reverse proxy or load balancer, TLS configuration, port mapping, and the application's health status. The local response already proves the process can answer on its internal path.