Learn→Object Storage & Blob Storage→Multipart Uploads & Resumable Transfers→1 of 6

Object Storage & Blob Storage • Multipart Uploads & Resumable TransfersEasy⏱️ ~2 min

What Are Multipart Uploads and Resumable Transfers?

Definition
Multipart upload splits a large file into smaller parts that upload independently and assemble into the final object on the server. If any part fails, only that part retries. Network interruptions do not waste already uploaded data.
Why Single PUT Fails at Scale
A single HTTP PUT request must complete or fail atomically. Uploading a 10GB file over a 100 Mbps connection takes 13+ minutes. Any network hiccup during those 13 minutes fails the entire upload. The client must start over, wasting bandwidth and time. For unstable connections or very large files, single PUT is practically unusable.
Multipart uploads eliminate this fragility. Each part is a separate HTTP request. A 10GB file split into 100MB parts becomes 100 independent uploads. Each takes about 8 seconds. Network failure during part 47 means retrying 8 seconds of work, not 13 minutes.
The Three Phase Protocol
Phase 1 - Initiate: Client requests to start a multipart upload. Server returns an upload ID (a unique identifier for this upload session). All subsequent parts reference this ID.
Phase 2 - Upload Parts: Client uploads each part with the upload ID and a part number (1, 2, 3...). Parts can upload in any order, in parallel. Server stores each part separately and returns an ETag (a hash of the part content) for each.
Phase 3 - Complete: Client sends the list of part numbers and their ETags. Server validates all parts exist, assembles them in order, and creates the final object. The upload ID becomes invalid.
Resumable Transfers
Because the server tracks parts by upload ID, uploads survive client restarts. The client stores the upload ID and which parts completed. After a crash, it queries the server for completed parts, then uploads only the missing ones. This is true resumability: close your laptop, reopen tomorrow, continue from where you stopped.
💡 Key Insight: Multipart uploads convert one fragile atomic operation into many robust idempotent operations. Each part either succeeds completely or fails completely, and failures are cheap to retry.

💡 Key Takeaways

✓Single PUT fails atomically: network hiccup during 10GB upload wastes entire transfer, requires restart

✓Multipart splits into independent parts: 100MB parts mean retrying 8 seconds of work instead of 13 minutes

✓Three phase protocol: initiate (get upload ID), upload parts (parallel, any order), complete (assemble final object)

✓Parts upload with upload ID and part number; server returns ETag hash for each part for integrity verification

✓True resumability: client stores upload ID and completed parts, survives crashes and network changes

📌 Interview Tips

1Start by explaining the failure mode multipart solves. A mobile app uploading a 2GB video on cellular: single PUT fails constantly. Multipart with 50MB parts means only 25 seconds of work at risk per failure.

2Walk through the protocol phases. Initiate returns upload ID abc123. Upload part 1 to /upload/abc123?partNumber=1, get back ETag. Repeat for all parts. Complete with list of (partNumber, ETag) pairs.

3For resumability, explain state management. Client persists {uploadId, completedParts: [{number: 1, etag: x}, ...]}. On restart, resume by uploading missing part numbers. No server side changes needed.

← Back to Multipart Uploads & Resumable Transfers Overview