A mobile gaming startup runs leaderboard and session logic on EC2 instances with local memory and disk. Players lose progress when instances restart and scaling out causes inconsistent scores across Availability Zones. The team wants stateless containers that scale horizontally. Which externalized state management design best enables stateless application scale?
Select an answer to reveal the explanation.
Short Explanation
You can scale smoothly when every container reads shared state instead of carrying it locally. Externalized state lets any container serve any player using Redis for fast-changing game data and DynamoDB for durable profiles.
Full Explanation
The Redis-and-DynamoDB design makes containers stateless: they keep no durable game data and retrieve shared state over the network, so any container can serve any player. ElastiCache for Redis provides fast in-memory access suited to ephemeral sessions and leaderboard data, while DynamoDB durably stores player profiles that must survive cache loss. Replicating session files with hourly rsync and keeping leaderboards on local filesystems fails because updates converge slowly, can conflict, and remain tied to individual hosts rather than being reliably shared during scale-out. Sticky ALB sessions with local container memory fail because they preserve stateful instances; restarts or rebalancing can lose progress, and sticky routing does not provide shared state across Availability Zones. Storing sessions in S3 and querying it for every leaderboard read fails because object storage is not designed for frequent, low-latency reads or transactional leaderboard updates. Exam caveat: ephemeral state belongs in a cache, but durable player data needs persistent storage. In practice, check Redis eviction and expiration settings and test DynamoDB partition-key behavior under expected load.