Challenge 1: Shared Hosting and .htaccess — Solution Walkthrough

Why .htaccess is a good architectural fit:

Each of the 500 customers has their own directory on the same physical
Apache server, but none of them should need root access to the main
server configuration just to set up their own redirect rules. Apache's
.htaccess mechanism exists precisely for this situation: a config file
placed directly inside a customer's own directory, whose settings
apply only to that directory, editable by the customer themselves
(e.g. via FTP or a hosting control panel) with no support ticket and
no access to httpd.conf required.

The performance trade-off:

Making this self-service capability possible costs something on every
single request: Apache has to check every parent directory of the
requested path for a .htaccess file before it can finish handling the
request, since any of those directories might contain overrides that
change how the request should be processed. Across 500 customers and
their full traffic volume, that's a real, continuous filesystem-check
cost the hosting company is choosing to pay in exchange for not having
to handle every customer's individual configuration requests manually.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own .htaccess section to the
exact scenario it's designed for — recognizing that the "who needs to
make changes, and do they have deploy access" question, not raw
performance, is what should drive the choice here, and that the
performance cost is a known, deliberate trade-off rather than a
surprise.