Design a Video Processing Pipeline, stage 3 of 14: decide
How does the system learn the upload finished?
The parts are in storage, but the video row still says uploading. Something has to move it to queued so processing can start.
The browser is the first to know the parts are uploaded, but it is also the least reliable participant: tabs close, laptops sleep, and clients can be buggy or malicious.
System so far· 4 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
- Request / response
- Bulk data
What you need to know
Video status is a state machine: a fixed set of states and the allowed moves between them.
uploading → queued → processing → ready ↘ failedEach move should happen because of a fact the system has checked, not because a participant said so.
Check
The browser says "all parts uploaded". Why not move the video to queued on that alone?Triggers fire more than once: a client retries its request, a storage event is delivered twice. Each trigger tries the same transition, so the transition must be safe to attempt twice. A conditional update does that:
UPDATE videos SET status = 'queued' WHERE id = $1 AND status = 'uploading';The first attempt changes one row. Every later attempt changes zero.
Think first
An instructor's upload finishes, and they close the laptop before the browser reports completion. What does the design need so this video doesn't stay 'uploading' forever?