A 311 mobile backend keeps open case drafts and uploaded photos only in process memory and local container disk so responses stay fast. What risk does that create on a cloud platform that may stop or multiply the process at any time?
Select an answer to reveal the explanation.
Short Explanation
Treat the process like a taxi that can be swapped mid-shift: anything left only on the seat disappears with the car. Session tables and uploads need a backing store. Local memory and disk are fine for scratch, not for business truth.
Full Explanation
Keeping open case drafts and uploaded photos only in process memory and local container disk creates a durability risk on a cloud platform that may stop, move, or multiply the 311 backend at any time. Business state that lives only in memory or ephemeral local disk disappears when the instance is replaced, rescheduled, or scaled out to a peer that never saw that local data. Durable case drafts and photo bytes belong in an attached backing store that outlives any single process.
The platform will not automatically replicate local disk to every region without configuration—that belief invents magic replication that does not exist for container ephemeral storage. OCI does not forbid ephemeral disk for temporary scratch; scratch is fine, durable business state is not. Process memory is not automatically snapshotted into Object Storage on every scale event; assuming so leaves drafts and uploads unprotected when the process dies.
Exam caveat: ephemeral local storage and memory are acceptable for caches and scratch, but anything the citizen must not lose when a replica vanishes must sit in a managed backing store (database, object storage, or equivalent).
Operational check: kill a backend replica mid-draft, bring traffic to a new replica, and verify the draft and uploaded photo still load from the backing store—not from the dead container’s disk or memory.