Challenge 1: Variable-Duration Requests — Solution Walkthrough

Recommended algorithm:

least_conn.

Why round robin is a worse fit here:

Round robin distributes requests purely by count, cycling through
each backend in turn with no awareness of how long any given request
actually takes to process. With requests randomly taking anywhere
from 50ms to 8 seconds, round robin can easily assign several of the
slow 8-second requests to the same backend purely by coincidence of
ordering, while a different backend sits comparatively idle after
finishing its own faster 50ms requests. The backend holding several
slow requests becomes a bottleneck that round robin has no way of
detecting or avoiding, since it never looks at how busy each backend
currently is.

Why least_conn is a better fit:

Per this chapter's own material, least_conn actively routes each new
request to whichever backend currently has the fewest active
connections — meaning a backend already tied up with a slow 8-second
request is less likely to be handed yet another new request, since
its active-connection count is already higher than a backend that has
already finished its own fast requests. This directly targets the
exact problem described: uneven request duration causing some
backends to become unintentionally overloaded.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the specific trade-off between round robin
and least_conn — blind request-count distribution vs. active-load-
aware distribution — is understood well enough to correctly diagnose
which algorithm actually fits a variable-duration workload, not just
recalling that least_conn exists.