Multipart upload

Amazon S3's API is the pattern other stores copy. The client calls an initiate, receives an upload id, PUTs each part, and calls complete with the list of part numbers and entity tags. Until complete runs, there is no readable object at that key.

Parts are independent. A failed part is retried without resending the others. Parts can go up in parallel, which is how a single fast disk beats one TCP stream. S3 requires each part except the last to be at least 5 MB, and caps the count at 10,000 parts. A 48 GB object in 100 MB parts is 480 parts, inside that cap. A mistaken 1 MB part size fails the minimum or forces an awkward last-part dance.

A render farm initiates a multipart upload for `spot-final.mov`, 22 GB. Twelve workers upload parts. Part 17 times out and is sent again. The complete call lists parts 1 through 220 with their ETags. Only then does GET return the movie. If the job crashes after initiate and never completes or aborts, the parts stay billed as incomplete storage. Operators who watch bucket size and not incomplete-upload counts miss that leak. Abort is a separate call. Complete with a missing part fails. The key still does not exist.

Multipart upload is not an HTTP multipart form. A browser form with `multipart/form-data` is one request that packages fields and a file. It does not have part numbers, an upload id, or a complete step. It is also not tus. tus tracks one offset on one URL. Multipart tracks a set of parts that can arrive out of order. Both resume. Mixing the client libraries produces a complete call the other server does not understand.

The ETag on a multipart object is not always an MD5 of the whole file. S3's multipart ETag is a hash of part hashes plus a part count. A recipient who checks that ETag against a local MD5 will reject a good file. Publish a whole-file checksum beside the object if the check has to be portable.