TikTok

The problem

"Design TikTok." People swipe through short videos, 15 to 60 seconds each, in a For You feed picked for them, mostly from creators they don't follow. Every swipe must start the next video at once, and a new video should reach feeds within a minute of posting.

This practice problem reuses the pattern of Design YouTube; what changes is the swipe. Park live streams, comments and direct messages: they are systems of their own.

The numbers

From the interviewer: 50 billion views a day (say 500 million people watching about 100 videos each), videos of about 30 seconds at about 1 Mbps, and half the views swiped away after about 2 seconds. To start each one at once, the app preloads the next 3, whole. A day is about 100,000 seconds (86,400 really).

what              working                 result
views             50 billion ÷ 100,000    500,000 a second
skipped           half of them            250,000 a second
sent              500,000 × 30 Mb         15 Tbps
never watched     250,000 × 28 Mb         7 Tbps
watched           15 − 7                  8 Tbps

A common slip is 500,000 views × 1 Mbps = 500 Gbps, as if each view lasted one second. With 86,400 seconds the waste is about 8 Tbps. Nearly half of what goes out is never watched.

Preloading: instant swipes, few wasted bytes

Fetching a video only when someone swipes to it saves almost nothing (a skipped video still fetches its first seconds, only later) and shows a black screen: 3 seconds of video (3 Mb) on a 5 Mbps phone link take 0.6 s, dozens of times in a few minutes. Preloading fewer videos whole doesn't help: the waste comes from downloading a whole video before anyone knows it will be skipped.

Preload only the first 3 seconds of each of the next 3 videos, and while a video plays, stay about 3 seconds ahead of it. A skip then wastes at most those 3 seconds: 250,000 × 3 Mb = about 750 Gbps instead of 7 Tbps, and what goes out drops from 15 Tbps to about 9. The next 3 seconds arrive in 0.6 s on that 5 Mbps link, long before they play. When someone closes the app, 9 seconds of video are left unwatched instead of 90.

Watch signals as events

Most views end with no tap, yet each one says something: watched to the end, watched twice, swiped away after a second. The app records one small event per view (video, seconds watched, loops, swiped) and sends them in batches, about every 10 views: 50,000 requests a second instead of 500,000. The feed service keeps each person's latest events for their next page and puts every event on a queue for the jobs that learn from them. TikTok's own 2020 description of For You says that finishing a longer video counts as a strong sign of interest.

Adding watch time to each video's row would be 500,000 writes a second, about 100 times what one database server handles, and a total loses who watched what. Counting only likes, shares and follows would leave most views unread.

The For You feed: candidates and a re-rank

The app asks for 10 videos at a time: about 50,000 feed requests a second, each picking from say 1 billion videos. Scoring every video for every request would be 50 trillion scores a second, so the work is split in two:

• A batch job, every few hours: learns from the events what keeps people watching, scores the library for each person and keeps about 500 candidates each. 500 million people × 500 ids × 8 bytes is about 2 TB, small enough to keep in memory.
• A light re-rank on each request: re-scores the person's 500 candidates with what they watched in the last few minutes, drops videos already seen, and mixes in a few posted minutes ago. That is 50,000 × 500 = 25 million scores a second, spread over many servers.

This is not Twitter's fan-out: For You doesn't come from follows.

Fast posting: one rendition first

Say that at the 8 pm peak, uploads bring 25% more transcoding work than the workers can do. The line grows: after an hour, a new video waits 15 minutes before its first job starts. Making all 5 renditions in parallel, as in YouTube, doesn't help while the line itself is that long. The phone's original file, at say 10 Mbps, would cost 10 times the 1 Mbps rendition on every preload and view, and some phones can't play it.

Use two lanes. The rendition most phones play goes on a fast lane that workers always take first; the other 4 wait on a slow lane. Say each rendition is about the same work: the fast lane brings a fifth of it, 25% of what the workers can do even at the peak, so it never waits. A 30-second video goes live about 10 seconds after it lands (3 segments of 10 seconds, made at once). The slow lane takes the overflow: while the peak lasts, its jobs start about 20 minutes late.

Same pattern as YouTube

Everything about moving bytes carries over: a signed URL so the app uploads straight to object storage, a storage event that puts transcoding jobs on a queue, workers that cut each video into segments and make its renditions, a video record with its manifest, and a CDN that sends the segments from edges near the viewers.

Summary

• Scope: YouTube's upload and CDN, plus swipes, For You, fast posting, watch signals.
• Numbers: 500,000 views a second; whole preloads would waste about 7 Tbps of 15.
• Preloading: the first 3 seconds of the next 3 videos, then 3 seconds ahead: about 750 Gbps wasted.
• Watch signals: one event per view, sent in batches, on a queue.
• For You: 500 candidates per person from a batch job, re-ranked on each request.
• Fast posting: the rendition phones play first, on a fast lane; the rest later.