Challenge 2: Compare Middleware Application Models — Possible Solution
====================================================================

THE SCENARIO
------------
A middleware adds a 200ms artificial delay for logging purposes (perhaps
it makes a synchronous call to an external logging service before
letting the request continue).

WHAT WOULD HAPPEN IF LARAVEL APPLIED IT GLOBALLY BY DEFAULT
------------------------------------------------------------------
If this middleware were registered the way Django's MIDDLEWARE list
works — added once, applied automatically to EVERY request the
application handles — then every single route in the entire application
would incur that 200ms delay on every request, regardless of whether
that particular route actually needed or benefited from this specific
logging behavior. This includes:

- Simple, high-traffic routes like a health-check endpoint or a static
  asset route that has no real need for this particular kind of logging.
- Routes that are already performance-sensitive, where an extra 200ms is
  a meaningfully large percentage of the total response time.
- API endpoints that might be called thousands of times per minute, where
  200ms × thousands of requests becomes a very real aggregate cost —
  additional server load, slower perceived response times for every
  client, and potentially a bottleneck under high traffic that has
  nothing to do with the routes the logging middleware was actually
  written for.

Because Laravel instead requires middleware to be explicitly attached
per-route or per-group (via ->middleware('name') or inside a
Route::middleware(...)->group(...) block), a developer can scope this
200ms-cost middleware ONLY to the specific routes where that logging is
actually valuable (say, a small set of admin or reporting endpoints),
leaving every other route in the application completely unaffected by
that cost.

WHY THIS IS A DELIBERATE DESIGN CHOICE, NOT AN OVERSIGHT
-------------------------------------------------------------
Laravel's opt-in model forces a developer to make a conscious decision
about which routes actually need a given middleware's behavior, rather
than defaulting to "runs everywhere unless something is added to
explicitly exclude it." This trades a small amount of extra setup
(explicitly listing ->middleware(...) on the relevant routes) for a
meaningful safety property: an expensive or narrowly-scoped middleware
can never silently affect routes it was never intended for, simply
because someone forgot to add an exclusion rule.

Django's global-by-default model isn't wrong — it fits Django's use case
well for things like AuthenticationMiddleware or SessionMiddleware that
genuinely SHOULD apply to nearly every request — but it does mean a
careless addition to MIDDLEWARE has a much larger, harder-to-scope blast
radius than the equivalent mistake in Laravel, where a middleware simply
isn't reachable by any route unless it's explicitly attached somewhere.

WHY THIS WORKS AS AN ANSWER
---------------------------
- The key insight is that Laravel's opt-in model shifts the DEFAULT risk
  from "accidentally affects everything" to "accidentally affects
  nothing (forgot to attach it anywhere)" — the second failure mode is
  much easier to notice and debug (the intended behavior just doesn't
  happen at all) than the first (unexpected latency or behavior showing
  up somewhere it shouldn't).