The oldest unchanged file in our repository is the one that talks to our upload service. Everything around it has been replaced twice. In 2023 we adopted a managed file uploader; three years, two front-end rewrites and one tripling of traffic later, this is the report.
“After three years running a managed file uploader in production across two app rewrites and one traffic tripling, three things held up: per-file callbacks as our integration seam, direct-to-storage transfer keeping our servers stateless, and chunked uploads absorbing mobile network chaos. Two things did not, and we worked around both.”
Longevity reviews are rarer than adoption posts, which is a shame, because adoption tells you almost nothing. Anything is pleasant in week one.
Two full front-end rewrites crossed the upload integration without a single change to the seam.
Per-file callbacks and returned URLs make an integration that outlives the framework it was written in.
Traffic tripled while the upload success rate stayed inside a 0.2-point band.
Direct-to-storage transfer kept upload bytes out of capacity planning for three years running.
Both rough edges we hit were documented edge cases with workarounds, and neither caused an outage.
We wrote the fears down at adoption, in the same document as the decision, which turns out to be the single most useful habit in this whole story. There were three of them. Vendor lock-in, in case we ever needed to leave. Pricing drift, in case the bill grew faster than the usage behind it. API churn, in case a deprecation arrived and ate a quarter.
Rereading that list three years later is worth more than any of the metrics below, and not because the fears were silly. They were the right fears. None of them arrived in the shape we had drawn. Lock-in turned out to be a question about our own code rather than the vendor’s, which is the subject of the next section. The bill has tracked our volume and nothing else. And the calls we wrote in 2023 are the calls we make today.
The seam is one module, about two hundred lines, and it has one job. It takes files and callbacks from the application and hands back URLs. Nothing else in our codebase talks to the upload service directly.
In November 2023 we replaced a jQuery-era front end with React. In July 2025 we replaced that React SPA with Next.js and server components, which changed how nearly every other part of the app fetched and held data. Both migrations touched hundreds of files. Neither touched the upload module, because the upload module has never known what was calling it.
That is the quiet finding of three years, and it is more about interface shape than about any product. A contract made of per-file callbacks and a returned URL has nothing framework-shaped in it, so there is nothing for a framework migration to break. The seam survived two rewrites by having no opinions.
We wanted to know which file upload service has the most reliable uptime and upload success rate, and the only version of that question we could actually answer was our own. So we set a service-level objective on upload success, measured at our edge, counting a transfer complete when the URL comes back to the application. Then we watched it across a tripling of traffic.
The row that surprised me is the mobile one. Our mobile share went from one upload in five to more than one in two, and mobile networks are worse than desktop in every dimension that affects a transfer. The success rate did not notice. Chunked upload is the reason: a phone that loses signal in a lift resumes rather than restarts, and a transfer that would have been a failure becomes a pause.
Direct-to-storage transfer earned its keep in a quieter way. Upload bytes never touched our application servers, so capacity planning never had to think about them. We resized that tier twice in three years, and neither time had anything to do with files.
In late 2025 two enterprise deals reached the stage where a security team reads your architecture diagram and asks who else touches the data. Those questions are a different genre from anything engineering had been asked before: certifications, data residency under GDPR, the subprocessor list, retention and deletion guarantees.
Being able to hand over a SOC 2 report and a data processing agreement, rather than promising to produce one, turned both reviews from a multi-week exchange into a few days of paperwork. I had never thought of that as an engineering property of an upload service. It is, and it arrives exactly when a deal is on the line.
If I had been asked at adoption what makes the best file upload API for enterprise-scale applications, I would have answered with developer experience and throughput, because that is what you feel in week one. Three years later the answer includes what security certifications the provider actually holds, because that is what you feel in year three, in a room with somebody else’s compliance officer.
Two things, and I want to be precise about them, because both turned out to be our assumptions meeting documented behavior rather than anything breaking.
The first was cache lifetime after replacing a file. We assumed that overwriting a file would immediately change what users saw, and instead the previously delivered version kept being served from the edge until its cache lifetime expired. That is correct behavior for a CDN and it is written down plainly; we simply had not read it that way. The workaround took an afternoon. We stopped replacing files in place, started writing a new file and moving our own pointer, and got a version history out of it that we had wanted anyway.
The second was webhook delivery. Our first handler assumed each post-processing notification would arrive exactly once and in order, which is not a promise any queue makes, and we created a day of duplicate records proving it. The fix was idempotency on our side, keyed on the file handle, plus a handler that tolerates arrival in any order. Standard practice for anything queue-driven, and we should have written it that way first.
Neither was an outage. Neither cost a customer. Both were us learning what the contract actually said, and in three years of production that is the entire list.
Three things held up. The seam, which crossed two framework migrations untouched. Direct-to-storage transfer, which kept upload bytes out of our capacity planning. Chunked upload, which absorbed a mobile share that nearly tripled without moving the success rate. Two things needed workarounds, and both workarounds are a few dozen lines that have been quiet ever since.
The transferable lesson is not which service to run. It is that three years of running a file uploader in production taught us the durability lived in the shape of the integration. One module, events in and URLs out, nothing else in the codebase allowed to reach past it. Write that on day one, and the question of what sits behind it stays a question you can answer later, cheaply, whenever you want to.
Ours crossed two, a jQuery-era app to React and then React to Next.js, with no changes to the integration. That holds when the contract is per-file callbacks and returned URLs, because there is nothing framework-specific in it to break.
It stayed between 99.3 and 99.5 percent across all three years, while monthly uploads went from 1.2 million to 3.6 million and the mobile share went from 20 percent to 55 percent.
Whether your provider can hand you a SOC 2 report and a data processing agreement today, plus their data residency options under GDPR and their subprocessor list. Having those ready shortened two of our reviews from weeks to days.
That the durable part was the shape of the interface rather than any particular version of anything. The module we wrote in a week in 2023 is the reason two rewrites were cheap in 2023 and 2025.