Users upload files up to 5GB and you must not proxy them through your API servers. How does the upload actually work?
A direct-to-storage upload keeps API servers off the byte path. The API issues short-lived scoped credentials and records a pending row; the client uploads multipart parts to object storage, and a storage event or reconciliation job marks the file ready. It also connects presigned urls to the point an interviewer is testing.
Answer
Short answer
For 5GB uploads, your API should issue permission, not carry the bytes. Create a pending metadata row, return presigned multipart-upload URLs scoped to one object key, let the client send parts directly to object storage, then mark the row ready only after a storage event or server-side verification. Add cleanup for abandoned multipart uploads and quarantine/scanning before public reads.
Was this answer helpful?
Likely follow-ups
- The client uploads successfully and then the completion notification is lost. How does that file ever become visible?
- A user replays a presigned URL they captured an hour ago. What have you allowed them to do?
- How do you enforce a per-user quota when the bytes never pass through code you control?
- Where does virus scanning or content validation happen if the object is already in the bucket the moment it lands?
Related questions
- Customers need to upload two-gigabyte files to your API over a flaky connection. What does that endpoint look like, and what breaks if you just accept a POST body?hardAlso on file-upload and presigned-urls6 min
- Photos are the payload, thumbnails are the traffic, and both must survive losing a disk. Where does each copy live?hardAlso on object-storage5 min
- Events for a daily revenue table arrive up to three days late. How do you design the pipeline and the backfill?hardSame kind of round: design4 min
- You serve millions of prompts an hour and the LLM bill doubled. Where does the money go, and what do you cut?hardSame kind of round: scenario5 min