Challenge 2: Why Turning Off proxy_buffering Would Make This Worse — Solution Walkthrough

Why the suggestion is likely to backfire:

Per this chapter's own warning box, disabling proxy_buffering means
Nginx passes each chunk of the backend's response straight through to
the client as it arrives, rather than buffering the full response and
letting the backend connection close quickly. With a client on a slow
mobile connection downloading a large file, the connection to the
backend itself would now stay open for the entire duration of that
slow client transfer — exactly the opposite of what's needed when the
backend is already under heavy load.

Why this makes the actual problem worse:

The team's real problem is backend connections staying open too long
under load. Turning off buffering ties backend connections directly to
how fast the slowest client's own network happens to be, meaning one
slow mobile client downloading a large file can hold open a backend
connection (and whatever resources that connection represents — a
worker slot, a database connection, memory) for far longer than
necessary, adding to the exact resource pressure the team is already
trying to relieve.

What would actually help instead:

Leaving proxy_buffering on (or ensuring it's genuinely on, if it
wasn't already) lets Nginx accept the backend's full response quickly,
freeing that backend connection almost immediately, while Nginx itself
handles the slower job of trickling that data out to the slow client
— exactly the protection this chapter describes buffering as
providing.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to a concrete,
realistic scenario where the "off is faster" instinct is specifically
wrong — correctly identifying that disabling buffering shifts cost
onto the backend connection, worsening the exact symptom the team is
trying to fix.