Challenge 3: Why an IIS Site's Own Application Pool Is a Meaningfully Different Guarantee — Solution Walkthrough

What Apache/Nginx typically share:

An Apache VirtualHost or Nginx server block is just a config block
telling the server which domain maps to which content — by default,
all VirtualHosts/server blocks on the same Apache or Nginx instance
are handled by that same instance's own shared pool of processes or
worker processes (Chapter 2). If one site on that server triggers
heavy load or a runaway process, per Chapter 2's own architecture
discussion, it can affect the shared resources every other site on
that same server instance is also relying on.

What IIS's per-Site Application Pool guarantees instead:

Because each IIS Site is tied to its own Application Pool, and each
Application Pool runs as its own separate worker process (w3wp.exe),
one Site's application misbehaving — crashing, leaking memory, using
excessive CPU — is isolated to that Site's own worker process. Another
Site on the same IIS server, running in a different Application Pool,
keeps running in its own separate process, unaffected by the first
one's problems.

Why this is a meaningfully different guarantee:

The difference isn't about how a request gets routed to the right
site (all three servers do that the same way, via Host-header
matching) — it's about what happens once a site is misbehaving. IIS's
architecture provides process-level isolation between sites as a
built-in default; Apache and Nginx's shared-process model, by
default, does not offer the same guarantee unless additional isolation
is deliberately configured.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise connects this chapter's own Sites/Application Pool
pairing back to Chapter 2's architecture material, correctly
identifying that the meaningful difference is about fault isolation
under a misbehaving site, not about the routing mechanism itself,
which is identical in spirit across all three servers.