Resumable browser uploads to S3 — presigned multipart with checksums?
614 views
30 of 106
1
The problem
Question presented to candidate:
"Users upload files of up to 50 GB from the browser. We do not want the bytes to pass through our API servers, uploads must survive a flaky connection or a page reload, and we need proof that what landed in S3 is exactly what the user picked. Walk me through the flow between browser, backend and S3."
What a strong answer should cover:
Direct-to-S3: the backend keeps the AWS credentials, starts the multipart upload, and hands the browser presigned URLs per part; the bytes go browser to S3, the backend only handles small JSON calls
Per-part integrity: the browser computes each part's SHA-256 (or CRC) and sends it as the checksum header that S3 verifies (a corrupted part fails with BadDigest); the composite checksum at Complete gives end-to-end proof
Resume: persist uploadId and file identity (name, size, last-modified) in localStorage or the backend; after a reload, the backend calls ListParts, the browser re-hashes its slices to confirm it is the same file, and uploads only the missing parts
Presigned URL scope and expiry: short TTL (minutes), one URL per part number, re-issue on expiry; SigV4 presigned URLs last at most 7 days and die with the signing credentials
Browser specifics: CORS must allow PUT and expose the ETag header, or the browser cannot read part ETags; parallelism limits and memory (slice the File, do not load it)
Server-side bookkeeping: authorisation before presigning, an uploads table, Complete called by the backend, and a lifecycle rule that aborts abandoned uploads
Clarifying questions expected:
Maximum file size and typical network (mobile, office)?
Must resume work across devices or only after a reload on the same browser?
What happens after upload: virus scan, transcoding, making it visible to other users?
Code / implementation expected: Optional — the endpoint contract and the browser loop; the example simulates presigning, checksum checks and resume.
s3
presigned-url
checksum
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Developers preparing for system design or full-stack interviews who know roughly what S3 is. The multipart mechanics themselves are covered on the S3 multipart upload page; this page is about doing it safely from a browser.
Difficulty: Medium
Verified with: Node 22.22 and Python 3.12 (both print identical output). S3 behaviour and limits are from AWS documentation, cited inline.
How to read this doc: Every idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact words an interviewer expects. All behaviour shown comes from running the example, which simulates S3 and the signing step in one process; the Verified section quotes the full output.
1. Why This Even Matters — A Story First
A museum accepts donated
The solution is hidden so you can try first
14 min read · 12 sections
4
Read the code
Presigned part URLs with per-part SHA-256: corrupted part, misused URL, tab reload resume, expired URL, composite checksum, lifecycle abort