Design TikTok

You're asked to design a short-form video app. A user opens it and a video is already playing, with no browsing and no search, and swiping up plays the next one. The videos are chosen for them, and the app learns from how they watch.

The delivery mechanics overlap with Design YouTube, and the encoding pipeline is a simpler version of the same thing. What's different is that there is no library and no navigation: the product is the recommendation, every video must start with no perceptible delay, and the ranking system has to work for a user it knows nothing about.

Clarifying the requirements

• How long are the videos? Fifteen to sixty seconds, which is why the whole file can be prefetched rather than streamed adaptively.
• How fast must the next video start? Instantly on swipe, meaning it has to already be on the device. This single requirement drives the client design.
• Is the recommendation system in scope? Yes, and unlike most media questions, it's the centre of this one rather than a side topic.
• How fast does new content need to circulate? Minutes. A video uploaded now should be able to reach an audience today, which rules out purely batch-computed candidate sets.
• Do we need follows and social features? Present, but secondary. The main feed is not follow-based, which is the product's defining difference from earlier social video.

Assume: sub-minute videos, instant playback on swipe, recommendation in scope, minute-level content circulation.

Back-of-envelope numbers

• Users: $1\text{B monthly}$, $300\text{M daily}$, each watching $100 \text{ videos/day}$
• Video views: $300\text{M} \times 100 = 30\text{B views/day} \approx 350\text{k views/sec}$
• Uploads: $50\text{M videos/day} \approx 600/\text{sec}$
• Video size after encoding: $\approx 3\text{ MB}$ for a 30-second clip, so storage grows $50\text{M} \times 3\text{ MB} = 150\text{ TB/day}$
• Egress: $30\text{B views} \times 3\text{ MB} = 90\text{ PB/day}$, essentially all of it from CDN edges
• Engagement signals: several per view, so $\approx 1\text{M events/sec}$ feeding the ranking system

The signal rate is the number worth highlighting. A million interaction events a second is a data pipeline in its own right, and it's what makes the feed adapt within a session rather than overnight.

High-level architecture

Components

1. Feed service. Returns a batch of ranked videos rather than one at a time.
2. Candidate generation. Narrows billions of videos to a few hundred plausible ones, cheaply.
3. Ranking model. Scores those candidates precisely for this user.
4. Video index. Metadata, content signals, and engagement statistics per video.
5. CDN edge. Serves the video files the client prefetches.
6. Event stream. Watch time, completion, likes, shares, skips.
7. Feature store. User and video features, updated continuously from the stream.

Deep dive 1: prefetching, and why the feed returns a batch

The product promise is that a swipe plays the next video with no wait. There is no way to fetch a video after the swipe and meet that, so the video has to already be on the device.

The feed API returns a batch of five to ten videos with their URLs and metadata, rather than one at a time. The client plays the first and downloads the next few in the background, so a swipe plays from local storage.

Three consequences worth naming:

• How many to prefetch is a real tradeoff. Too few and a fast swiper outruns the buffer; too many and you waste the user's cellular data on videos they never reach. Adapting the depth to connection type and to observed swipe speed is the refinement that shows product thinking.
• Prefetch progressively. Fetch the first seconds of the next video at high priority and the remainder at low, so the swipe is instant even if the full file hasn't arrived.
• Batching costs freshness. A batch ranked thirty seconds ago can't reflect the last three videos watched. Keeping batches small, and letting the client request the next batch early, is how the design keeps in-session adaptation without giving up prefetch.

Because videos are short, the whole file can be fetched rather than streamed in segments, which removes the need for adaptive bitrate mid-video and simplifies delivery considerably compared to long-form. Pick the rendition once from the device and connection, and download it.

Deep dive 2: candidate generation and ranking

Scoring billions of videos for each of thirty billion daily requests is not possible, so the pipeline is staged: cheap and broad first, expensive and precise last.

Candidate generation cuts billions to a few hundred using several independent sources, each cheap:

• Content similarity to what the user has engaged with, retrieved by embedding lookup.
• Collaborative signals. Videos liked by users with similar histories.
• Trending and fresh content in the user's language and region.
• Follows and social graph, which is a minor source here rather than the primary one.

Running several sources in parallel and merging matters more than any one being good: each has a different blind spot, and their union is what stops the feed from collapsing into a single narrow topic.

Ranking then scores those few hundred with a model that would be far too expensive to run over the full catalog. The target is not a click but a combination of predicted watch time, completion rate, and interaction probability. Using watch time as the primary signal rather than likes is worth stating, since it's implicit feedback available on every video from every user, while explicit signals are sparse and biased.

Diversity and freshness are applied after ranking, as a re-ordering step. A purely score-ordered feed becomes repetitive, showing five near-identical videos in a row, and repetition is what makes people close the app. Enforcing spacing between videos from one creator or one topic costs a little predicted engagement per video and improves session length, which is the metric that actually matters.

Deep dive 3: cold start, for users and for videos

Cold start is the problem this product is unusually exposed to, because there's no browsing behaviour to fall back on. It appears in two forms.

A new user has no history. The feed starts from broadly popular, high-quality content in their language and region, and the important design property is that early signals are weighted heavily, since the first few videos are effectively an interactive interview, and skipping three cooking videos should change the feed immediately. This is a strong argument for updating features from the event stream in near-real-time rather than in a nightly batch.

A new video has no engagement history, which matters more here than in most recommender systems, since fifty million uploads a day means a large share of the catalog is always cold. The standard approach is staged exposure:

• Show the video to a small audience selected from its content signals: what's in the video, its audio, its captions, and the creator's history.
• Measure completion rate and interaction on that small sample.
• If it performs above the bar for its cohort, widen the audience; otherwise stop.
• Repeat, so a genuinely engaging video escalates through progressively larger audiences within hours.

This is what makes it possible for a creator with no followers to reach millions, which is the product's central promise. It also needs a guard: the sample has to be large enough to be meaningful, or noise promotes videos randomly and demotes good ones.

Content signals are what make cold start work at all, since they're the only features a brand-new video has. Extracting embeddings from the video, its audio, and its text at upload time, as part of the encoding pipeline, is what gives ranking something to work with before any human has watched it.

Deep dive 4: the signal loop

A million events a second flow back from clients, and how quickly they reach the ranking system determines whether the feed feels responsive or stale.

Two paths, different latencies. Aggregate video statistics and user embeddings can update in near-real-time from the stream, so a skip affects the next batch. Full model retraining is a batch job on a much slower cycle. Confusing the two is a common mistake: you don't retrain a model in seconds, but you can absolutely update features in seconds, and that's what produces the in-session responsiveness users notice.

Not every signal means what it appears to. A quick skip is a strong negative, but a partial watch on a long video may be positive. A rewatch is among the strongest positives available. Defining the signal semantics is a modelling decision with direct product consequences, and mentioning that the definitions matter, not just the collection, is a senior-level observation.

Reserve part of the feed for exploration. A model trained only on what it previously showed will narrow over time, because it never observes how users would respond to content it stopped surfacing. Reserving a small fraction of the feed for exploration, meaning content the model is uncertain about, is both what keeps the system learning and what gives new videos a path in. It costs measurable short-term engagement and is worth it, and being able to say why is a strong signal in this question.

Common pitfalls

• Fetching the video after the swipe. There is no way to meet the latency requirement without prefetching.
• Ranking the full catalog. Candidate generation has to narrow the set before any expensive scoring.
• Optimizing for likes. Explicit signals are sparse and biased; watch time is available on every view.
• A purely score-ordered feed. Repetition ends sessions, and diversity has to be enforced after ranking.
• No exploration budget. The model narrows, and new creators never get a first audience.

Leveling the answer

Related lessons

Design YouTubeHard

Ingest and transcode continuous user uploads, then deliver them worldwide.

Design the Reddit HomepageMedium

Rank and serve a feed that stays current without recomputing everything.