Short video feed - the next swipe is already downloading

Why this design

"Design TikTok" is often answered as "design YouTube, but shorter", and that answer misses both hard parts. A short-video feed has no search box and no subscriptions page to fall back on: the ranked feed IS the product, it is recomputed with every swipe, and it has to start each video in under 200 ms because a new one starts every 15 seconds. The question tests whether you can design ranking and delivery as one system, and whether you can put numbers on the bandwidth you waste to make swipes feel instant.

What you will learn

• Candidate generation versus ranking: why you retrieve about 1,500 items cheaply from several sources and score only about 500 expensively.
• Why the feed is ranked per request rather than precomputed, and what that costs at 80,000 requests a second.
• Prefetch: how many videos ahead, how many seconds of each, and what each choice costs in wasted egress.
• Why the first segment of every video is encoded and cached differently from the rest.
• The learning loop: watch time as the label, the explore budget for new uploads, and the feedback loop where a model only learns from what it showed.

How to read this board

1. Press Play. THE PHONE asks for a page, RANKING builds it from candidates, scores it and re-ranks it for diversity.
2. The page returns and the player prefetches the start of the next three videos from DELIVERY.
3. Watch events flow into LEARNING, which updates features within seconds and the model every hour.
4. Then pages 1 to 6 and the DATA MODEL.
5. Argue with what the board leaves in: prefetched videos ranked before the viewer reacted, the explore budget, and the cold tail that misses the CDN.

Ask these before drawing anything

• What is the objective? Total watch time, completions, shares and "not interested" are different labels and produce different feeds. Most real systems combine several into one weighted score; say which.
• How fresh must ranking be? Per request (reacts to the last swipe) or per session (computed once)? This board says per request.
• What start-up time is acceptable? Under 200 ms from swipe to first frame is the bar for a feed that feels instant.
• How much may we spend on bandwidth that nobody watches? It must be a number, because prefetch converts it directly into start-up time.
• How much exposure do new uploads get? Without an explicit explore budget, a new creator is never shown and therefore never learned about.
• Upload and transcoding are their own design (see the video-transcoding board). Here they are an input: a video arrives already encoded into a ladder.

Functional

• GET a page of 10 ranked videos for this viewer, excluding anything already watched.
• The player starts the next video on swipe without a visible spinner on a typical 4G connection.
• Every impression and watch event (watched ms, completed, replayed, swiped at ms, liked, shared) is recorded.
• New uploads enter the feed within minutes of publishing through an explore pool.
• No two consecutive videos from the same creator; at most 3 of 10 from one topic cluster.

Non-functional

• Feed request p99 under 150 ms server side.
• Time to first frame p75 under 200 ms for prefetched videos, under 600 ms for a cold start.
• Wasted prefetch bytes under 3 % of total egress.
• A model or feature store outage degrades the feed (trending fallback); it never shows an empty screen.

Out of scope

• Upload, transcoding and moderation.
• Comments and messaging.
• Ads insertion (the ad-serving board) - though it takes slots from this same page.