title File Upload Flow type actor User type database "Files DB" User -> Browser: select file Browser -> Upload API: request upload URL Upload API -> Browser: pre-signed URL Browser -> Storage Service: upload file directly Storage Service -> Browser: upload complete Browser -> Upload API: confirm upload Upload API -> Storage Service: verify file exists Upload API -> "Files DB": save file record Upload API -> Browser: 200 OK + file URL Browser -> User: show uploaded file
What this diagram shows
Follow the file, not the requests. It goes browser to storage, one hop. Your API only ever handles two small JSON calls: "give me a URL" and "I'm done." That's the whole trick.
It's also why this pattern survives big files and heavy upload traffic without your server noticing. S3 is the usual storage box here, but GCS and R2 presign the same way.
Step-by-step flow breakdown
When to use this flow diagram
- Justifying the pattern in an architecture review. This picture does most of the arguing.
- Security docs on how upload URLs get scoped and expired.
- Debugging failed uploads: URL generation, the direct PUT, or the confirm step?
- Converting a team that still proxies files through the backend.
Common variations
Add virus scanning
Add Upload API -> Scanning Service: scan file after verification, before the record gets saved.
Multipart upload for large files
For big files, show the chunks: Browser -> Storage Service: upload part 1..N.
CDN distribution
Add Storage Service -> CDN: replicate file once the record exists.
Related flow diagram examples
Frequently asked questions
What does this diagram show?
A presigned upload end to end. The file goes browser to storage directly. The API just issues the URL and records the result.
Why not just upload through the API?
Bandwidth, memory, and timeouts, mostly. Proxying a 2GB file through your API buys you nothing except three new ways to fail.
Can I use this template for free?
Yes. Point it at your own storage setup and export. No account.