Managing state across ephemeral instances

WHAT THIS TESTS The interviewer is probing whether you understand that auto-scaled instances are cattle, not pets, and that state must live outside them.

A GOOD ANSWER COVERS Start from the principle that any instance can be terminated at any moment, so it must hold no irreplaceable state. Classify state and route each kind to the right managed service. User sessions and ephemeral fast-access data go to a distributed cache like Redis or Memcached. Transactional, relational data goes to a managed database such as RDS, Aurora, or Cloud SQL, which handles replication and failover. Large binary objects go to object storage. Shared hierarchical files that several instances must read and write go to a managed network file system. Local instance disk is used only for scratch and cache that can be regenerated. This keeps the compute tier stateless and freely scalable.

COMMON WRONG ANSWERS Storing uploads or session data on the local disk, which is lost when the instance is replaced. Relying on in-process memory for state shared across requests. Treating sticky sessions as durability rather than a routing optimization. Building a custom replication scheme when a managed service already solves it.

LIKELY FOLLOW-UPS How do you handle in-flight requests during scale-in. Sticky sessions versus a shared session store. How do you keep the cache consistent with the database. What about stateful workloads that genuinely need local persistent volumes.

ONE CONCRETE EXAMPLE An e-commerce app runs a stateless web tier behind a load balancer. Carts and sessions live in Redis, orders in Aurora, product images in S3, and shared report templates in a managed file system. When the auto-scaling group scales from four to ten instances and back, no user loses a cart and no data is stranded, because the instances themselves hold nothing durable.