Articles
S3 Multipart Upload Interview Questions: Parts, Checksums, and Abandoned Uploads
Practice S3 multipart upload interview questions through failed-part recovery, checksum interpretation, completion order, and abandoned-upload cleanup.
A multipart upload interview question is rarely just “What is the maximum part size?” The interesting task is recovering a large upload after a connection drops, proving the completed bytes are correct, and preventing unfinished parts from accumulating charges. A strong answer names the state the client must retain, explains what S3 can confirm, and separates a part identifier from an object integrity check.
This guide uses an original practice scenario, not a claim that a particular employer asked it. AWS documentation is the source for S3 behavior; the uploader design and test cases are editorial inferences.
The answer in one minute
Amazon S3's multipart sequence is initiate, upload numbered parts, complete. The initiate call returns an upload ID. Each UploadPart sends that ID and a part number; S3 returns a part ETag and, when configured, checksum information. The completion request names the part numbers and matching ETags. S3 concatenates completed parts in ascending part-number order. An interrupted part can be sent again without re-uploading the successful parts. These are documented S3 mechanics, not a general guarantee about every object store.
Your application still needs a durable upload record. Store the bucket, object key, upload ID, intended part layout, each completed part number and returned ETag, checksum choice, and whether completion or abort has been requested. On resume, reconcile this record with S3 rather than assuming every previous response reached the client. Complete only after the expected parts are present and integrity checks agree. If the operation is abandoned, abort it and configure lifecycle cleanup for old incomplete uploads.
Practice scenario: the missing third part
Imagine a 400 MiB video divided into four 100 MiB parts. Parts 1 and 2 returned success. The client sent part 3, then lost its connection before receiving a response. Part 4 completed. A user presses Resume from a second laptop. The interviewer asks whether to restart, upload part 3, or call Complete immediately.
First question: what does the new laptop know? If the upload ID and object key were stored only in local browser memory, it cannot safely discover “its” operation from the key alone. Several multipart uploads can target the same key. The application should persist a logical upload record associated with the authorized user and target object, including the S3 upload ID. Do not hand an arbitrary upload ID to another user without checking ownership and permissions.
Second question: did part 3 land? A lost response does not prove failure. Use the known upload ID to list its uploaded parts, remembering that results can be paginated. AWS says ListParts reports finished parts, not still-running requests, and cautions against blindly building a completion request from a listing; the client should retain its own part-number and ETag ledger. Reconcile the ledger with the listing and any inflight workers. If part 3 did not finish, resend only part 3. If it did finish but the ETag was not captured, reconcile that value before completion. A retry using the same part number replaces the previous part; therefore a second sender must use the same intended byte range and checksum, not an accidental different slice.
Third question: what is the commit point? Completion is separate from the last UploadPart. Do not expose the object to downstream consumers merely because four part uploads appear successful. Make the completion call with the intended ordered part-number/ETag pairs, then verify the resulting object metadata and your expected checksum. If the Complete response itself is lost, do not issue a fresh multipart upload blindly. Check the operation/object state and reconcile whether completion succeeded. A durable application state machine might use initiated → uploading → reconciling → completing → completed and a separate aborting → aborted branch. That state machine is an implementation design, not an AWS API contract.
Part numbers, order, and failed retries
S3 allows part numbers from 1 through 10,000. A part number identifies both a part and its position in the final object; completion assembles parts in ascending part-number order. Basic multipart uploads do not require consecutive part numbers. However, AWS documents a crucial exception: with additional multipart checksums, part numbers must be consecutive starting at 1. If you use a checksum-enabled flow, build the client planner around that rule rather than discovering it at completion. The multipart overview is explicit about both behaviors.
Interviewers often probe a quiet corruption bug: worker A uploads bytes 200–299 as part 3, times out, and worker B retries part 3 with bytes 300–399 because its offset calculation used a new chunk size. S3 accepts the replacement part number, but the assembled object is wrong. The repair is not merely “retry with exponential backoff.” Keep an immutable manifest for the upload: part number, byte start, byte end, expected length, and locally computed checksum. Retries can change transport attempts, but not the logical mapping from part number to bytes.
The other subtlety is what you can conclude from a successful part response. An HTTP success tells you S3 accepted a part under a particular upload ID and number. It does not mean the entire object is available, and it is not proof that your application selected the correct source bytes. Compare intended byte ranges and checksum evidence. If the source file has changed between laptops or sessions, stop and begin a new logical upload rather than completing a mix of two versions.
ETag is not a universal whole-file hash
A familiar interview trap is local_md5(file) == HeadObject.ETag. AWS explicitly says the ETag after multipart completion is not necessarily the MD5 of the object data. Multipart assembly, checksum configuration, and encryption modes make the simple equality unreliable. Use ETags for the part identifiers required by the completion protocol, and use an explicitly selected supported checksum mechanism for data integrity. The S3 integrity guide distinguishes full-object checksums from composite checksums derived from part-level values.
For a high-assurance uploader, state the algorithm and checksum type at initiation, calculate the right value over the intended bytes, send supported checksum fields, and inspect the stored checksum after completion. Do not compare a full-object digest with a composite digest as though they were interchangeable. A BadDigest response means the provided and calculated checksums disagreed; treat that as a correctness failure, not as permission to skip validation on the next retry. For a product requiring cryptographic evidence of the source file, decide whether the S3-provided checksum algorithm satisfies that requirement or whether to persist an application SHA-256 as separate metadata and verify it independently.
This is a useful moment to state a limit: S3 can validate that received bytes match a provided checksum, but it cannot know whether the client intended to upload the correct user's file, correct version, or correct media range. Those are application-level invariants. In an interview, make both layers visible: transport integrity and business identity.
What should happen to unfinished uploads?
An initiated multipart upload does not expire by itself. AWS retains successfully uploaded parts until the upload is completed or aborted, and those parts can incur storage and request charges. An application should explicitly abort an operation after cancellation, permanent validation failure, or a defined inactivity window. A bucket lifecycle rule using AbortIncompleteMultipartUpload provides a safety net for operations the application failed to clean up. See AWS's multipart pricing and cleanup guidance.
Do not claim that one abort call instantly proves every in-flight part has vanished. AWS notes that part requests already in progress may still succeed or fail after an abort request; coordinate workers and inspect the upload state before asserting that cleanup is complete. A practical design marks the logical upload cancelled first, stops scheduling new parts, waits for or fences active workers, then aborts and records the result. Lifecycle cleanup remains a backstop, not the primary user-facing cancel behavior.
The deletion policy needs a business window. A creator uploading over a weak mobile network may resume tomorrow; a seven-hour inactivity rule could destroy valid work. Define the supported resume period, warn users when it ends, and align the lifecycle expiration with that promise. This time window is a product choice, not an AWS default.
Failure table for a strong interview answer
| Observation | What it establishes and Safe next step |
|---|---|
UploadPart times out after sending bytes | What it establishes: Outcome is unknownSafe next step: Reconcile that part; retry its immutable byte range if needed. |
| Same part number appears with the wrong expected length | What it establishes: The manifest and remote state disagreeSafe next step: Stop completion, investigate, and replace with the correct bytes. |
| All part calls succeeded, but Complete failed | What it establishes: The object may not be committedSafe next step: Read the error, reconcile upload/object state, then retry only when safe. |
Checksum mismatch or BadDigest | What it establishes: Integrity assertion failedSafe next step: Check source version, ranges, algorithm, and checksum type. |
| User cancels with workers still sending parts | What it establishes: Cleanup may race requestsSafe next step: Fence workers, abort, and verify; retain lifecycle cleanup. |
The table is an editorial troubleshooting exercise. It is deliberately narrower than a generic S3 consistency guide: it focuses on one resumable upload's part ledger and commit boundary. If asked about competing uploads to the same key, state that this introduces a separate overwrite/versioning decision.
How to practice explaining the design
Start your answer with the upload ID and one durable manifest. Draw four numbered parts and mark part 3 as “unknown outcome,” not “failed.” Ask which checksum algorithm and type the application selected. Then walk through the reconciliation, one-part retry, completion call, and post-completion verification. This sequence exposes the interviewer-relevant assumptions without drowning in API syntax.
Next, test an adversarial variant: the uploader is restarted after part 3 was accepted but before the database committed its ETag. Can your service recover, or will it send a different part 3? The right answer depends on whether the source bytes and layout remain stable. A second variant: a user uploads a new version of the file to the same logical destination. Distinguish that new upload from resuming the old one; use an application upload identity and appropriate object-key or versioning policy.
Finally, explain your observability. Count incomplete uploads by age and tenant, checksum failures, repeated part attempts, completion failures, and abort failures. Track bytes stranded in incomplete parts where available and alert when the cleanup backlog grows. An error budget for uploads should include both successful object availability and correct content, not only HTTP 2xx rates.
Closing answer
In a concise interview response, say: “I persist the upload ID and immutable part manifest, retry only missing or uncertain parts after reconciliation, complete with the correct part-number/ETag pairs, verify with the configured checksum rather than treating the ETag as a universal MD5, and abort abandoned work with lifecycle cleanup as a backstop.” Then spend the remaining time on the failure the interviewer chooses.
Sources and Further Reading
- AWS: Uploading and copying objects using multipart upload
- AWS: Checking object integrity for data uploads
- AWS: Configuring lifecycle rules to delete incomplete multipart uploads
- AWS: Multipart upload limits
Research checked September 28, 2026. S3 behavior and SDK defaults can change; confirm the current documentation and the exact checksum mode used by your client.