In this chapter
We'll meet multipart uploads — splitting one large object into smaller, independently uploadable real parts, so a single dropped connection only costs a small retry instead of restarting the whole transfer — and see exactly how it rescued GreenMart's own 40GB compliance export.
The Problem in Real Life
The finance team needs to upload a single, real 40GB export — five years of historical receipts, bundled for a compliance audit. The first attempt fails twice, timing out partway through. "Every time it fails," the engineer mutters, "it starts completely over from zero."
Sarah nods. "That's exactly the problem multipart uploads solve. Split it up, and one bad connection doesn't cost you the whole real file."
Why does one failed connection mean starting the whole 40GB upload over from the beginning?
Mike
One Giant Request vs. Many Real, Independent Pieces
Small, independent real parts
A large object is split into chunks, each uploaded separately — one failed part only costs a small retry, not the whole file.
Genuine parallelism, not just resilience
Independent parts can upload over multiple real connections at once, meaningfully cutting total upload time for large files.
Multipart Uploads
A multipart upload splits one large object into smaller, real, independent parts, uploads each separately (in any order, even in parallel), and has the object storage system assemble them into one complete real object only once every part has actually arrived.
- The real, three-step shape of a multipart upload. First, a real "initiate" call tells the object store GreenMart is about to upload one logical object in multiple real pieces, and gets back a real upload ID tying them together. Second, each real part — a chunk of the file, commonly tens of megabytes each — is uploaded independently via its own real PUT request, tagged with a part number and that same upload ID. Third, a real "complete" call, listing every part's number, tells the object store to assemble them, in order, into one final, complete real object.
- Why this genuinely fixes the finance team's real problem. If one specific part fails to upload — a dropped connection, a timeout — only that one real, small part needs to be retried, not the entire 40GB file from the beginning. This turns a single, fragile, all-or-nothing real transfer into many smaller, genuinely resilient ones, each with a real, low individual cost of failure.
- A real, second benefit: genuine parallelism. Because each part is a real, independent upload, GreenMart's own upload tooling can send several parts at once, over several real connections in parallel, instead of one slow, serial stream — a real, direct way to cut total upload time for very large files, not just a resilience improvement.
- A real, honest trade-off: incomplete uploads can linger. If an upload is initiated but never actually completed — abandoned parts sitting in the object store, uploaded but never assembled — those real parts still consume real storage space and real cost until they're explicitly cleaned up. Most object storage systems offer a real, automatic policy for aborting and removing abandoned multipart uploads after a set period, which the next-but-one chapter, Lifecycle Management, covers precisely.
GreenMart's finance team's export finally succeeds — not because the connection got any more reliable, but because a single 40GB all-or-nothing transfer became many small, real, independently retryable ones.
Key Takeaway
A multipart upload splits one large object into smaller, real, independently uploadable parts — turning a single fragile transfer into many resilient ones, with the real, added benefit of genuine parallelism, and one honest trade-off: an abandoned upload's parts still cost real storage until cleaned up.
Why This Matters
As GreenMart migrates larger and larger real assets — bulk exports, product videos, historical archives — into object storage, multipart uploads are the real, practical mechanism that makes those transfers reliable at all, rather than a single fragile request one dropped connection can undo entirely.
GreenMart now has the real mechanism for handling objects too large for a single PUT — reliably and, often, faster too. The next chapter turns to a different real concern: keeping track of an object's own history over time, through versioning.