Design a Video Processing Pipeline, stage 13 of 14: change it
Paid instructors want a fast lane
Under the Sunday peak, every worker is busy and each job holds a worker for around 12 minutes. Something has to give for a paid job to start within a minute.
System so far· 8 parts
Select a component to see what it is responsible for and which state it owns.
- 1Instructor browser → Video API: Create upload, report parts, poll status
- 2Instructor browser → Object storage: Upload parts via presigned URLs
- 3Video API → Object storage: Complete multipart upload, verify object
- 4Video API → Postgres: Video row and job row in one transaction
- 5Transcode workers → Postgres: Claim lease, heartbeat, fenced completion
- 6Transcode workers → Object storage: Read raw upload, write attempt output
- 7Reconciler → Postgres: Find abandoned uploads and orphaned output
- 8CDN → Object storage: Origin fetch on cache miss
- 9Student player → CDN: Manifest and segments
- Request / response
- Bulk data
What you need to know
0 of 2 checks done
When every worker is busy, a new job starts only when some worker finishes. With 12-minute jobs on a saturated fleet, that wait depends on when the next job happens to finish: often seconds, sometimes minutes.
Priority changes which job a free worker takes next. It doesn't create a free worker.
Check
Paid jobs get top priority. Every worker is mid-way through a 12-minute standard job. A paid job arrives. When does it start?Three ways to make room, each with a cost:
- Reserve workers for paid jobs: some sit idle. That idle time is the price of the promise.
- Preempt a running standard job: its work so far is thrown away, and standard users wait longer.
- Autoscale: new instances take minutes to boot, too slow to guarantee one minute.
Work it out
Paid uploads arrive at 0.5 a second at peak and take 750 seconds each. Using Little's law, about how many paid transcodes are in flight at once?