A few years ago, I was reviewing a candidate who was technically brilliant with syntax but struggled during the architectural part of the interview. I asked him a simple question: "What happens to your variables once the page finishes loading in the browser?" He looked genuinely confused and insisted that the server should just keep the objects in memory for the next click to save time. He had spent three days trying to debug a "bug" where a user's session data wasn't persisting, not realizing he was trying to use a global variable instead of $_SESSION. He didn't understand that PHP is essentially a "burn after reading" language.

When an interviewer asks you about the request lifecycle, they aren't just checking if you can recite a manual. They want to know if you understand the "shared-nothing" architecture of PHP. If you don't grasp this, you'll make fundamental mistakes with state management, caching, and performance optimization.

The Path from the Browser to the Script

The lifecycle doesn't start in your index.php; it starts long before that. When a request hits the server, it usually lands on a web server like Nginx or Apache. The web server doesn't actually know how to "run" PHP—it just knows how to handle HTTP. This is where the SAPI (Server API) comes in. Whether it's PHP-FPM (FastCGI Process Manager) or the older mod_php, the SAPI is the bridge that tells the PHP engine, "Hey, I have a request here; please execute this specific file."

Before a single line of your code runs, PHP has to compile your script into opcodes. In a production environment, you'll have OPcache enabled. This is a critical point for interviews: OPcache stores the precompiled script bytecode in shared memory so PHP doesn't have to parse and compile the file on every single request. If you mention OPcache during this explanation, you're signaling that you've actually worked on production-grade systems, not just local XAMPP stacks.

Execution and the Shared-Nothing Model

Once the opcodes are ready, PHP executes your code from top to bottom. It initializes the superglobals (like $_GET, $_POST, and $_SERVER) and runs your logic. I always tell my juniors to visualize this as a fresh slate. Every single request is a brand new universe. The memory is allocated, your classes are instantiated, your database connections are opened, and then—the moment the final byte of the response is sent to the client—everything is wiped clean.

This "shared-nothing" approach is why PHP is so stable. A memory leak in one request won't crash the entire server for every other user because the process is recycled. However, it's also why we need external tools like Redis, Memcached, or database sessions to remember who a user is between Page A and Page B. If you're asked how to maintain state in PHP, the answer is never "a static variable"; it's always "external persistence."

The Shutdown and Cleanup Phase

The lifecycle doesn't end the millisecond the HTML is sent. There's a final phase: the shutdown sequence. PHP triggers any registered shutdown functions and destroys all remaining objects in memory. If you've used fastcgi_finish_request() in an FPM environment, you can actually send the response to the user and then continue performing heavy tasks (like sending an email or logging analytics) before the process finally dies.

When you're answering these questions in an interview, try to walk through it like a story: Request → Web Server → SAPI → OPcache → Execution → Response → Shutdown. It shows you see the big picture, not just the code inside the brackets.

📋 Practical Task

Tracing the Request Execution Flow with a Custom Logger

To truly visualize the "fresh start" nature of the PHP lifecycle, you are going to build a diagnostic script that proves the lack of persistence between requests.

Requirements:

• Create a file named lifecycle_test.php.
• Define a static variable inside a class (e.g., class Tracker { public static $count = 0; }).
• In the script, increment that static variable: Tracker::$count++;.
• Use file_put_contents() to append the current value of Tracker::$count and a timestamp to a local file called lifecycle.log on every request.
• Add a register_shutdown_function() that appends a "Process Terminated" message to the same log file.

The Goal: Refresh your browser five times. Open lifecycle.log. If you understand the lifecycle, you will see the count is 1 every single time, followed by "Process Terminated," rather than counting up to 5. Your task is to successfully implement this and write a one-sentence comment at the top of your file explaining why the number never increases.