Challenge 2: When the Original Constraints Change — Solution Walkthrough

Why the original recommendation should NOT still hold:

Scenario 1's IIS recommendation was justified entirely by the
platform constraint — an existing Windows/.NET, internal-only
deployment. Once the tool is rewritten as cross-platform and
containerized, that exact constraint no longer exists: there's no
longer a Windows/.NET platform commitment driving the choice, and the
new deployment's own profile (public internet traffic, presumably
higher concurrency, likely multiple container instances) matches
Scenario 2's own decision criteria far more closely than Scenario 1's.

Re-running the framework:

  - Platform constraint: gone — no longer tied to Windows/.NET.
  - Configuration model: likely benefits from centralized,
    version-controlled config for a containerized deployment, fitting
    Nginx's own model well.
  - Concurrency profile: public internet traffic implies higher,
    more variable concurrency than the original 50-employee internal
    tool.
  - Reverse-proxy/load-balancing needs: containerized, likely
    multiple instances — squarely Nginx's own strength (Chapter 6).

Conclusion:

The service has moved from matching Scenario 1's own profile to
matching Scenario 2's, so Nginx becomes the better fit going forward
— not because IIS was ever "wrong" for the original job, but because
the job itself changed in exactly the dimensions this chapter's
framework is built to track.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise directly tests this chapter's own warning box — that
the framework describes fit for a specific job's constraints, not a
permanent ranking — by walking through what happens when those
constraints genuinely change, correctly re-deriving a new answer
rather than defending the original one out of habit.