Object Storage & Blob Storage • Multipart Uploads & Resumable TransfersMedium⏱️ ~2 min
State Persistence and Cross-Session Resumability
Resumability across process restarts, browser refreshes, or device reboots requires durable client side state. Without persistence, a network interruption or application crash forces the upload to restart from zero, wasting bandwidth and time.
The minimal resumable state includes the session identifier or upload URL, the total object size, the chosen part or chunk size, and a map of completed parts with their checksums or byte ranges. For Amazon S3 multipart, this means storing the upload ID and a list of part numbers with their corresponding entity tags (ETags). For Google Cloud Storage resumable uploads, store the session URL and the last server confirmed byte offset. This state must be persisted to disk or stable storage after each part completes.
Browser based uploads face unique challenges. In-memory state is lost on page refresh. Direct-to-S3 multipart uploads are fast but not inherently cross-session resumable unless the client persists state to IndexedDB or local storage. Protocols like TUS (Tussle Upload Protocol) solve this by moving state management to a server proxy, enabling seamless resume after refresh, but at the cost of proxying all upload bandwidth through that server, adding latency and egress costs.
Mobile applications benefit greatly from state persistence. Dropbox clients persist upload session metadata locally, allowing uploads to resume after app restarts or device sleep. Google Drive similarly tracks chunk progress so large video uploads can survive intermittent connectivity without user intervention.
💡 Key Takeaways
•Minimal resumable state: session ID or URL, total size, part size, and map of completed parts with checksums or ETags
•Amazon S3 multipart: Store upload ID and list of part numbers with ETags; on resume, query missing parts and continue
•Google Cloud Storage resumable: Persist session URL and last confirmed byte offset; resume by sending next byte range
•Browser uploads: In-memory state is lost on refresh; persist to IndexedDB for cross-session resume or use TUS protocol with server side state at cost of proxy bandwidth
•Mobile apps (Dropbox, Google Drive): Persist upload session metadata locally to survive app restarts, network changes, and device sleep
📌 Examples
Browser client using S3 multipart: On each part completion, write {uploadId, parts: [{number: 1, etag: '...'}]} to IndexedDB; on page load, restore and resume missing partsTUS protocol: Client sends upload metadata to TUS server, which returns a unique URL; all subsequent chunks POST to that URL; server tracks state so client can resume after any interruption
Dropbox desktop client: Stores upload session state in local SQLite database, enabling resume after process crash or system reboot without user intervention