Architecture: The Frontend and The Kernel

It's a Client-Server App

When you type code in a cell and press Shift+Enter, your browser does not execute it. The notebook interface is just a frontend — a display layer. The actual execution happens in a separate process called the Kernel. Here is the full request-response cycle:

1. Frontend (Browser): You type x = 5 + 3 and press Shift+Enter. The browser serializes this as a JSON message.
2. Notebook Server: Receives the message and forwards it to the appropriate Kernel over a WebSocket connection.
3. Kernel: A persistent background process (usually CPython) that evaluates the code, updates its in-memory state, and generates output.
4. Response: The output (8, or a plot, or an error traceback) is sent back through the server to the browser, which renders it below the cell.

This architecture means the Kernel is stateful — it remembers everything you have run since it started, like a long-running Python session.

Kernel Management

The Kernel is the "brain" of your notebook session. Understanding how to manage it is essential:

• Interrupt Kernel (■ button or I, I shortcut): Sends a SIGINT signal to the running process — equivalent to pressing Ctrl+C in a terminal. Use this when a cell is taking too long or you accidentally wrote an infinite loop.
• Restart Kernel: Kills the Python process entirely and starts a fresh one. All variables, imports, and loaded data are wiped from memory. The cell outputs remain visible on screen, but they are now stale — they reflect a state that no longer exists.
• Restart & Run All: The single most important habit in notebook work. Before sharing or submitting a notebook, always do this. It proves your notebook executes correctly from top to bottom in a clean environment, with no dependency on hidden state.