A GIS desktop tool keeps long-lived local state, while a related web API should scale behind a load balancer. Which design principle should guide the web tier?
Select an answer to reveal the explanation.
Short Explanation
The web API should travel light—no stuffed suitcase under the seat—so ALB can hand requests to any healthy instance. The chunky GIS desktop can stay stateful; don’t pretend it scales like a stateless API.
Full Explanation
The horizontally scaled web API should stay stateless behind an Application Load Balancer, while the city accepts that the stateful GIS desktop tool—with long-lived local state—does not scale the same way. Stateless API instances can be replaced freely; session or shared state lives in external stores when needed. Do not let the desktop’s stateful nature dictate sticky, non-scalable patterns for the web tier.
Making the web API sticky to a single EC2 host with all session files on instance store and no shared state service fails by concept because it destroys horizontal scale and ties sessions to ephemeral disks. Forcing the GIS desktop and the web API to share one global writable NFS root as their only scale strategy fails because a shared writable root is not a substitute for a stateless API design and can create locking and blast-radius issues. Placing both workloads on one Reserved Instance and disabling the load balancer fails by collapsing resilience and elasticity for “simplicity.”
Exam caveat: Horizontal web tiers → stateless behind ALB; stateful thick clients may remain stateful—do not force one pattern onto both. Sticky instance-store sessions and single-box designs are classic wrong answers.
Operational check: Confirm API instances store no unique local session files required for correctness, ALB health checks replace bad nodes cleanly, and GIS desktop state remains understood as non-horizontally-scaled. If API scale-in drops user sessions stored only on that host, the web tier is not stateless.