An analytics service runs on cloud compute nodes that are automatically destroyed and recreated during scale-in and scale-out events. After each event, data the service had written to the nodes' local disks is gone. Which design change keeps autoscaling while preventing the loss?
Select an answer to reveal the explanation.
Short Explanation
Treat cloud compute nodes like rental cars: you hand them back and you never leave your luggage in the trunk. Data that has to survive goes on storage that lives independently of the node. A bigger trunk doesn't help when the car gets returned.
Full Explanation
Computational persistence is the separation of durable data from compute that may be ephemeral. In elastic cloud environments, compute nodes are disposable: autoscaling, maintenance and failures destroy and recreate them, and instance-local or ephemeral disks are typically lost with the node. Data that must survive is written to persistent block volumes that can be detached and reattached, to a managed database or to object storage, all of which have life cycles independent of any single node. Increasing node size enlarges local disks without changing their life cycle, so the data is still lost when the node is replaced. Writing to a temporary directory and copying on shutdown depends on a graceful shutdown hook that may never run during a failure or forced termination, and any data written since the last copy is lost. Holding the data in memory and rebuilding from user requests offers even less durability, since memory is cleared when the node is recycled and the original data may never be requested again. Exam caveat: ephemeral local storage is still useful for caches and scratch space that can be regenerated. Operational check: terminate a node in a test environment during a write workload and confirm that all committed data remains available from the persistent store afterward.