Short Video Feed
Ingest and process short videos, deliver a low-latency personalized feed and enforce deletion across recommendations and media caches.
Ingest and process short videos, deliver a low-latency personalized feed and enforce deletion across recommendations and media caches. This worked design targets SDE-3; the scale figures below are exercise assumptions, not claims about a named company's implementation.
Clarify the prompt
| Ask the interviewer | Decision to record |
|---|---|
| Upload/playback or recommendation ranking first? | Separate the media plane and discovery plane. |
| What are startup-time, moderation and geographic-rights policies? | |
| Can upload publish before moderation/transcoding finishes? | Assume only an approved playable rendition is discoverable. |
Requirements and scope
The core deliverable is: Ingest and process short videos, deliver a low-latency personalized feed and enforce deletion across recommendations and media caches. The first design implements the APIs below and the state constraints in the data model. Agree the latency, freshness, retention and failure policy before adding infrastructure. Every successful acknowledgment must have an explicit meaning: accepted intent, committed state or completed external work. These are separate milestones.
Capacity and bottleneck reasoning
Assume ten million uploads/day at 20 MB: 200 TB/day raw before renditions. At 100 million daily viewers watching 30 minutes at 2 Mb/s, delivery is about 45 PB/day. CDN hit ratio and bitrate dominate cost; upload metadata QPS is not the main bottleneck.
Keep average and peak demand separate. Add replication, indexes, retries and safety headroom to raw arithmetic before selecting capacity. Load-test the busiest ownership key and recovery traffic as well as uniform happy-path throughput.
APIs and data model
- POST /videos/uploads -> scoped multipart upload
- POST /videos/{id}/publish {version} -> processing or playable
- GET /feed?cursor=... -> permitted videos and playback manifests
video(id,owner,upload_version,state,moderation_version,deleted_at)
rendition(video_id,version,codec,bitrate,manifest_key)
feed_session(id,user,model_version,candidate_cursor); exposure(id,video_id,position)Authorize resource ownership at the API boundary; do not trust IDs or state supplied by a client. Bind retry identity to the caller and payload for mutating operations. Reject an incompatible replay instead of returning an unrelated stored result.
Component relationships
Read the diagram
Follow the labeled relationship panels; they are separate directed paths, not one global timeline.
Step-by-step design
1. Establish the authority
Upload to immutable storage through scoped URLs. Verify content, dispatch bounded transcode and moderation jobs, and publish only a generation whose required outputs are complete. Retries cannot publish an older rejected generation.
2. Make retries and concurrent work safe
Retrieve and rank bounded candidates, apply policy/rights filters and return short-lived playback access where needed. Log impressions and watch-time with stable identities; deduplicate repeated events and resist bot amplification.
3. Scale and recover the critical path
Serve adaptive bitrate chunks from CDN, prefetch only a bounded next-video window and adapt to bandwidth. Deletion immediately removes discovery eligibility and blocks authorized playback, then purges caches and applies storage retention policies.
Worked request and concurrency example
Video V uploads at generation 2. Transcoding completes but moderation is pending, so the feed excludes it. After approval, its immutable rendition manifest becomes discoverable. A client prefetches the next two videos rather than the entire feed, limiting waste. If V is later removed, current policy blocks further access even while purge propagation is in progress; previously downloaded bytes cannot be recalled from a viewer's device.
Failure and recovery walkthrough
A viral video creates a hot key. CDN distribution, origin shielding and request coalescing protect storage; adding metadata database replicas alone will not solve media egress. A failed transcode leaves the generation processing/failed, never partially playable without an explicit rendition policy.
Read the diagram
This numbered trace follows one scenario; explain the durable evidence at each transition.
Decisions and alternatives
| Decision | Trade-off |
|---|---|
| Alternative 1 | Aggressive prefetch lowers swipe startup latency but wastes bandwidth and device energy. Bound it by network quality and viewing probability. |
| Alternative 2 | Precomputed feeds are cheap and stable; online ranking adapts quickly but adds feature/model latency. Playback should degrade independently when ranking fails. |
Operational contract
Track processing age, playable-publish failures, startup time, rebuffer ratio, bytes per watched minute, CDN hit ratio and deletion propagation. Test viral traffic, failed renditions and removal during active playback.
Choose alert thresholds from the agreed user-facing objective. Assign an owner for stuck work and a replay/repair procedure that preserves the original business identity. Bound queue depth, concurrency and recovery throughput so an outage does not produce an uncontrolled catch-up burst.
Foundation, senior and staff depth
- Foundation: explain the user action, model, first complete request and the correctness constraint without relying on a list of technologies.
- Senior: defend this lesson's partition/coordination boundary, capacity estimate and failure recovery; explain the cost of the rejected alternative.
- Staff: identify failure domains and operational ownership, stage a rollout with measured guardrails, and state when rollback stops being safe.
Practice before revealing the answer
Spend 45 minutes: 5 clarifying scope, 7 on capacity/APIs/state, 12 on the first architecture, 15 on the concurrency and failure examples, and 6 on trade-offs and operations. Draw your own design before comparing it with this chapter.
Question: What makes a short-video system different from an image feed with larger files?
Show answer and explanation
Answer: Video needs asynchronous encoding, multiple bitrates, chunked playback, startup/rebuffer targets and much higher egress. Recommendation signals include exposure and watch duration, and prefetch creates a bandwidth-versus-latency trade-off.
Verification and rollout
Reproduce the worked example using two concurrent actors or a repeated request where applicable. Inject the stated failure between the durable transition and its acknowledgment; verify the resulting state and user-visible outcome. For read/ML paths, test missing or stale dependencies and verify the documented fallback still enforces permissions. Use a small canary, compare correctness and user-facing latency with the baseline, and roll back when those guardrails regress. Do not use an average throughput number as evidence that a tail-latency target is met.
Primary technical reference
Official documentation for the mechanism used in this exercise. This lesson is an original interview design, not a description of undisclosed company internals.
Related study
Before this design, review these mechanisms and identify which owns the critical state transition:
Use the Interview Playbook to adapt the depth and timing, then return to the question breakdown overview.
What makes a short-video system different from an image feed with larger files?
Your design draft
Clarify assumptions, explain your approach, and test the difficult cases. Save your draft, then compare it with the study notes.
Self-review checklist
Self-guided practice. Automated AI feedback and code execution are not connected.