Signals that it’s a large-upload problem
- Files from tens of MB to many GB
- Mobile or flaky networks
- Must survive drops and app restarts
- Work happens after the upload
Climb the ladder. The pre-signed URL is only rung 1.
Most of the interview is about drops, killed apps and files that aren’t what they claim to be.
Stream it through the API?
Bad: POST through the app server
A server held for 27 minutes; every byte crosses it twice.
Good: Pre-signed URL
The API grants permission; bytes go straight to storage.
The API hands out permission, not bandwidth
Create checks auth and quota, picks the key and returns a 15-minute pre-signed URL. The 4 GB goes straight to a private bucket.
Multipart: a drop costs one part, not the file
16 MiB parts, three in flight, each retried alone. A drop loses at most 48 MiB, about 20 seconds. Complete stitches all 239 parts into one object.
The phone kills the app mid-upload. Start over?
The fix
No. The client saves the upload ID and finished parts after each one, then asks the server what it has and sends the rest.
9 TB
unlisted, billed parts, capped by a 7-day rule
If 5% of 50,000 daily uploads die halfway, 1.25 TB of unfinished parts lands every day. They’re invisible yet billed until AbortIncompleteMultipartUpload clears them.
Signed is not checked
Uploads land in a private quarantine bucket. An event triggers type checks from the bytes and a malware scan; only clean files are copied to the bucket you serve.
Say it like this
The API only grants permission. Bytes go straight to storage in 16 MiB parts, resumable after any drop, checksummed, and quarantined until a scan clears them.