Files & Object Storage

Uploads that do not go through your process, the bucket/key/object primitive underneath every provider's SDK, and what still has to happen after the bytes land.

File Uploads Through the Backend

The obvious path — client to backend to storage — makes your request handler a bandwidth-bound file mover, and it is still the right answer sometimes.

Q · What actually happens when a user uploads a file to your API, and what does routing those bytes through your process cost?

Presigned URLs

Your backend issues a signed, expiring permission slip; the client uploads directly to storage; your process never sees a byte — which is the benefit and the cost.

Q · How can a client write to your private storage bucket without holding your credentials, and what do you give up by never seeing the bytes?

Object Storage

A bucket holds objects addressed by a key. That primitive — not any provider's SDK — is what you are actually programming against.

Q · What is the storage primitive underneath every cloud file API, and how does it differ from the filesystem you are picturing?

Choosing an Upload Path

File size, privacy, scanning, processing and serving decide the architecture. There is no default that is right for all five.

Q · Given this specific file feature, should the bytes go through my backend, straight to storage, or somewhere else entirely?

What Happens After the Bytes Land

Stored is not ready. Scanning, transcoding and thumbnailing are background work with a state machine, and skipping the state machine is how unscanned files get served.

Q · A file is in the bucket. What still has to happen before anyone should be allowed to use it?

Serving Files

Private files need a check on every read; public files need a CDN. Serving both through your API is the one option that is wrong for both.

Q · How does a stored object get back to a user, with authorization enforced and without your service moving every byte?