A backend is a program running as a process that listens on a network port, accepts requests, applies rules, communicates with other systems, and returns responses. Files preserve code, memory holds working state, and external databases preserve durable state. This mental model makes later framework behavior predictable instead of magical.
A recipe is not a meal, and source code is not a running application. Python reads source code and creates a process. The operating system gives that process memory, CPU time, file access, and network access. A server process binds to a port such as 8000; clients address it using a host and port.
Open a terminal and run a temporary web server from an empty practice directory:
Visit http://127.0.0.1:8000. Return to the terminal and press Ctrl+C. You have started a process, bound a port, sent an HTTP request, observed a response, and delivered an interrupt signal.
Verify the port while the server is running in another terminal:
The evidence is an HTTP status line and headers—not merely a browser page.
Variables live inside a process. Restarting the process removes them. Two worker processes also have separate memory. Therefore a dictionary can support a learning experiment, but it cannot safely own shared tickets, users, permissions, or approvals. PostgreSQL will own those facts.
Model calls may last seconds, stream partial output, fail remotely, or continue in a background worker. You must know which process owns the work, where progress is recorded, and how a client reconnects. Durable AI run records belong in PostgreSQL; temporary stream coordination may use Redis.
Run the temporary server, capture the full curl -i response in your learning log, stop the server, and repeat the request.
Acceptance criteria: the first request returns a status; the second fails to connect; you can explain which process state changed.