Why not store uploads on local PaaS disk?

WHAT THIS TESTS This is a stateless-architecture fundamentals question. The interviewer wants to see that you know PaaS compute is ephemeral and horizontally scaled, so local disk is the wrong place for durable data.

A GOOD ANSWER COVERS A PaaS runs your app in containers or instances that the platform may restart, redeploy, or replace at will, and it scales by adding more identical instances behind a load balancer. The local filesystem is ephemeral: it is reset to the image on every new container, so a file written today is gone after the next deploy or restart. It is also per-instance, not shared, so an upload handled by instance A is invisible to instance B, and a later download request routed to B fails. The standard pattern is to stream the upload to a managed object store such as Amazon S3, Google Cloud Storage, or Azure Blob Storage, which is durable, virtually unlimited, and shared across every instance, then store just the object key or URL in your database. Often the client uploads directly using a pre-signed URL to avoid routing large files through the app.

COMMON WRONG ANSWERS Assuming the disk persists across restarts. Assuming all instances share one filesystem. Proposing sticky sessions to keep a user on the same instance, which is fragile and still loses data on redeploy. Storing large blobs in the database.

LIKELY FOLLOW-UPS What is a pre-signed URL and why use it? How do you serve files back efficiently, perhaps via a CDN? How do you handle access control on private objects? What is the difference between block, file, and object storage?

ONE CONCRETE EXAMPLE A user uploads a profile photo to a Flask app on Heroku running three dynos. Writing it to ./uploads saves it on one dyno only; the next request hits another dyno and the photo is missing, and the daily dyno restart deletes it entirely. Instead the app stores the photo in S3 under avatars/user-123.jpg and saves that key in Postgres, so any instance can serve it and it survives every restart.