Short answer: use multipart upload for large Node.js backup archives, and keep the upload ledger in your job database so a worker can resume, complete, or deliberately abort the transfer.

The deciding constraint is throughput under interruption. A developer-tools platform may turn thousands of receipt images and records into one tar.gz , then retain that exact file for an audit. Holding the archive in memory or restarting one giant PUT after a broken connection makes the retry unit needlessly large. Multipart changes the retry unit from “the whole audit archive” to “one numbered part.”

This is an operational choice, not a promise that multipart wins for every object. Small receipts can stay on a single PUT. Large backup bundles should not.

The before-and-after model

Picture the original worker as a three-box diagram in words: archive file -> one request -> object storage. If the request stops near the end, the next attempt returns to byte zero.…