A travel booking startup runs ticketing APIs on EC2 instances behind an ALB and loses shopping carts whenever an instance is replaced during scaling events. Traffic triples on holidays and the team must scale horizontally without session loss while keeping read latency under 20 ms for seat maps. How should state be redesigned?
Select an answer to reveal the explanation.
Short Explanation
Tired of losing carts when servers vanish? You keep servers disposable by moving memory outside them into shared externalized stores. Cache handles fast seat reads, database keeps bookings safe across scaling.
Full Explanation
Externalizing state allows stateless compute where any EC2 instance can serve any request because session data lives in ElastiCache for Redis for sub-millisecond reads ideal for seat maps and durable booking records live in DynamoDB for highly available persistent storage with auto scaling. This design survives instance replacement and supports horizontal scaling during holiday triples without affinity. Local memory with sticky sessions creates affinity that breaks during replacement and prevents even load distribution. EBS files per instance trap state on specific hosts and nightly copies risk data loss and staleness. Keeping state in threads and scaling vertically hits hardware limits, increases blast radius, and retains the core fragility. For the exam, associate stateless scaling with external session plus durable store, and in practice set Redis TTLs for carts and use DynamoDB conditional writes for booking consistency.