metrics
▼Upload success rate
45%↑
███████░░░░░░░░░
▼Avg retries per 1GB file
6.2↑
▼User frustration
high↑
architecture
Stage 1: Naive Full-File Upload
┌─────────┐ ┌─────────┐ │ Client │ │ Server │ │ │ POST /upload (5MB file) │ │ │ │──────────────────────────>│ │ │ │ │ │ │ │ <── 5MB over network ──> │ Write │ │ │ │ 5MB to │ │ │ ✓ 200 OK │ disk │ │ │<──────────────────────────│ │ └─────────┘ └─────────┘
Every save uploads the entire file
story
$cdstage_q1[1/7]
# Resumable File Uploads
Your study group loves the file-sharing app you built. Someone tries to upload their 50MB presentation over coffee-shop WiFi. At 98% complete, a passing skateboard enthusiast jostles the table; the laptop disconnects. The upload fails. All 49MB must be re-sent. Your friend misses the deadline and blames you. Technically their fault, but morally? Yours.
Uploading large files in a single HTTP request is fragile. If the connection drops mid-transfer, all progress is lost—the client must restart from byte zero. A 5GB video upload over flaky home WiFi can fail 10 times before succeeding. Users experience this as "your app is broken." You need resumable uploads that survive network hiccups.
[?]
A 5GB upload fails at 98%. Should users really have to re-upload all 4.9GB? What if you could save progress?
$selectstrategy↑↓ j/k enter
→Retry entire upload with exponential backoff
Split files into 1–5MB chunks with upload sessions
HTTP range requests with server-side partial write support
Cloud File Storage & Sync|stage 1/7
▓░░░░░░14%
^→ nav|↑↓ select