**Turned failed multi-gigabyte uploads from a routine restart-from-zero into a resumable transfer, cutting the bandwidth wasted on retries by a large relative margin.** ## Outcome Turned failed multi-gigabyte uploads from a routine restart-from-zero into a resumable transfer, cutting bandwidth wasted on retries by a large relative margin. ## Context This was work on Canvas, Pfizer's global content platform, where authors uploaded multi-gigabyte media and documents from offices and homes through enterprise VPNs and proxies. I owned the resumable-upload implementation while working within the platform maintained by its product and infrastructure collaborators. ## Problem Canvas, Pfizer's global content platform, let authors publish large media and document assets: multi-gigabyte files, uploaded from offices and homes over enterprise VPNs and corporate proxies. On a plain form upload, a single dropped connection near the end of a 3 GB transfer meant starting again from zero, and on flaky links it could mean a file never landing at all. This was the hardest problem I owned on the platform, because the failure was not in my code, it was in the network, and the fix had to make an unreliable channel behave reliably. ## Constraints - Unreliable networks: enterprise VPN and proxy hops dropped long-lived connections, so any upload had to treat interruption as the normal case, not the exception. - File size and memory: multi-GB payloads could not be buffered whole in PHP memory or carried in a single request. - Enterprise proxies: intermediaries buffered and timed out large request bodies, so the transport had to survive middleboxes I did not control. - NDA: absolute throughput and volume figures are confidential, so results are relative. ## Decisions and trade-offs - Plain multipart form upload (rejected): one request, no resume. Simple, but any interruption discards the whole transfer and multi-GB bodies blow past request and memory limits. - Presigned S3 multipart direct-to-bucket (considered, rejected as the primary): the browser uploads parts straight to S3. It offloads bandwidth, but it pushes part-tracking, retry, and integrity logic into every client, leaks bucket-facing surface into enterprise environments, and gives the platform no clean resumption protocol or server-side control over accepted content. - TUS resumable upload on Laravel (chosen): the open TUS protocol chunks the file and tracks a server-side offset, so a client that drops at 80 percent resumes at 80 percent by asking the server how far it got. Laravel terminated the TUS endpoint, persisted the offsets, and assembled completed uploads into AWS S3 for durable storage. It gave one resumable file upload contract every client could speak, kept the bucket behind the application, and let the server enforce size and type before anything was finalized. TUS won because the binding constraint was resumability over hostile networks, and it is the one option that makes resumption a first-class protocol feature instead of client-side bookkeeping. ## Implementation I implemented the Laravel side of the TUS endpoint, persisted server-side upload offsets, and assembled completed uploads into AWS S3 within the shared platform. This kept the bucket behind the application and allowed size and type checks before finalization. ## Results Multi-gigabyte uploads stopped being all-or-nothing. A transfer interrupted by a VPN drop resumed from its last acknowledged offset instead of restarting, so the bandwidth wasted on retries fell by a large relative margin and uploads that used to fail outright now completed. Resumable ingestion became standard platform behavior, and the same TUS pattern recurred across four separate engagements in my tracked work, which is the clearest signal that it solved the problem generally and not just once. ## Takeaways Treat hostile networks as normal operating conditions. A server-side resumable offset makes recovery a protocol feature instead of unreliable client-side bookkeeping.