Video & media
Video upload - one file in, seven encodes out
Resumable upload, the transcode fan-out, and why it says processing
What this board gets wrong on purpose
The tension
Every upload gets the full ladder eagerly, and the 500 MB master is kept forever on top of it. Most videos on a service like this are watched fewer than ten times, so the 1080p AV1 rung - which costs 7.4 of the 14 core-minutes each source minute burns, more than every other rung combined - is usually encoded for nobody. The honest alternative is to encode 360p now and the rest on first demand, which cuts the compute bill by more than half and makes the first viewer of a cold video wait. Nothing on this board can tell those two videos apart at upload time, because the only signal that separates them - whether anyone watches - arrives after the money is already spent.
1. Requirements
A creator uploads one file. The service owes them two things that pull in opposite directions: an immediate, durable receipt, and a video that eventually plays everywhere. Everything below follows from separating those two promises.
Functional
- Upload one video file of up to 256 GB and receive a durable receipt before any encoding has started.
- Survive a lost connection: an interrupted upload resumes from the last byte the server acknowledged, not from zero.
- Transcode every accepted upload into a ladder of renditions and package it for both DASH and HLS.
- Extract a poster frame and a scrub-bar storyboard sprite from the source.
- Expose the state of a video - uploading, processing, ready, failed - and the reason for a failure.
- Retain the master so the whole catalogue can be re-encoded when a better codec arrives.
Non-functional
- Upload API availability 99.9 percent monthly. A chunk PUT must be retryable without corrupting the session.
- Time to first playable rendition: p50 under 90 seconds, p95 under 8 minutes. Full ladder p95 under 30 minutes.
- Master durability 11 nines. A lost master is content loss that no backup of the database can undo.
- No accepted byte is ever silently dropped: an upload either becomes a master object or is reported missing.
- Cost per uploaded minute is a tracked, alarmed figure, because it is the dominant variable cost of the product.
Questions to ask before designing this
- What is the size DISTRIBUTION of uploads, not the average? The mean drives storage, the p99 drives chunking and timeouts, and on a video product they are an order of magnitude apart.
- Is the ladder fixed or per-title? Per-title encoding moves the compute bill by 20 to 30 percent and adds a complexity-analysis pass before any encode starts.
- How long must a resumable session stay resumable? Seven days of resumability is seven days of half-uploaded objects you are paying to store and may never complete.
- Do we also have to ingest live? If yes, the segmenter and packager are shared with a system that cannot buffer, and that constraint reaches back into this board.
- What happens to a master after five years - archive tier, or delete it and keep the top rendition as the new source?
- Is the top rung a paid feature? If it has revenue attached, the eager-versus-lazy encoding argument has a different answer.
- Who is allowed to delete a video, and does delete mean the renditions, the master, or both? The answer decides whether the storage curve can ever go down.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, an 11-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 11walkthrough steps
- 5tables34 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Upload, transcode, deliver - and pay for the bandwidth.