A transit-authority portal stores each clerk’s session only as files on one back-end worker’s local disk while a load balancer can send the next request to any instance. What design change restores free fan-out?
Select an answer to reveal the explanation.
Short Explanation
Local session files glue a clerk to one machine—like a locker that only one gym branch can open. A shared session store or a token unpins them so the next hop can land anywhere. That is what lets you add or remove workers freely.
Full Explanation
Free fan-out behind a load balancer requires that any healthy worker can serve the next clerk request. Session files on one worker's local disk create affinity by accident: the next request may land on a peer that cannot read those files, breaking the transit-authority portal after scale-out or restart. Moving session state to a shared store (Redis, database, clustered cache) or issuing a client token (signed cookie or JWT with server-validated claims) restores interchangeability so the balancer can distribute freely.
Permanently pinning every clerk to the first worker and disabling scaling fails because it abandons horizontal capacity and creates a single point of failure. Baking the local session directory into each new VM image at build time fails because sessions are runtime, per-clerk data—not static image content—and still do not sync live writes across instances. Lengthening sticky-session timeout fails because stickiness papers over the missing shared state and collapses under worker loss, drain, or uneven load.
Exam caveat: sticky sessions are a temporary workaround, not the scalability design goal; the exam favors shared externalized state or client tokens for stateless workers.
Operational check: terminate one worker mid-session and confirm the clerk continues on another instance without re-authentication failures or lost portal context.