Process-based vs Thread-based: The Isolation Dilemma

Every backend runtime must answer a fundamental question: "How do we handle two users at the same time?"

The answer defines the stability of your entire platform.

Process-based Models (The "Apartment" Approach)

PHP-FPM uses processes. Each request gets its own dedicated process. It has its own memory space. It shares nothing with other requests.

• Isolation: If one request crashes (Segfault), only that user is affected. The rest of the server stays alive.

• Memory: No race conditions on global variables because there are no shared global variables.

• Cost: High. Creating processes is slow and consumes more RAM.

Thread-based Models (The "Roommates" Approach)

Java, Go, and Node.js (internal libuv) use threads. Threads live inside a single process and share the same memory heap.

• Efficiency: Extremely fast to spawn. Low memory footprint.

• Communication: Easy to share data between requests (e.g., a global in-memory cache).

• The Danger: Shared State.

  • If one thread corrupts the memory, the entire application can crash.

  • If one thread blocks the loop (in single-threaded async like Node), everyone waits.

Why this choice dictates architecture

This is why PHP is famously stable in messy codebases. You can write terrible code, memory leaks, and fatal errors—and the runtime simply recycles the process after the request. The server stays up.

In a thread-based runtime (like Java or a long-running Node app), a memory leak is a ticking time bomb that eventually kills the whole instance.

The Takeaway: Process models prioritize Safety and Isolation. Thread models prioritize Efficiency and Shared State.

Understanding this helps you decide not just which language to use, but how much you need to trust your own code.