Design TikTok

TikTok's design question is interesting precisely because it breaks the pattern of every other social system. There is no fanout: the feed is not assembled from who you follow, it is generated by a model. Say that early — it reframes the whole answer.

Requirements

Functional

• An endless personalised video feed, opening straight into playback.
• Upload short videos with music, effects and hashtags.
• Like, comment, share, follow.

Non-functional

• The first video plays instantly — this is the entire product experience.
• Scrolling to the next video must never wait.
• Recommendations adapt within a single session.

1B monthly users, 200M daily
Average session 60 minutes, ~15 seconds per video → ~240 videos per session
200M × 240 = 48B video views/day ≈ 550,000 views/second

That number is the design constraint: half a million video starts per second, each of which must begin in well under a second.

Why there is no fanout

In Twitter or Instagram, the candidate set is bounded by your follow graph, so precomputing a per-user list is feasible. Here the candidate set is **the entire corpus**, and it is ranked by predicted engagement for you specifically. Precomputing a list of ids per user is still done — but as a recommendation pipeline output, not a graph traversal.

The practical consequence: a brand-new video with zero followers can reach millions of people, which is the product's defining property and falls directly out of this choice.

The recommendation pipeline

                     billions of videos
                            │
  ┌─── CANDIDATE GENERATION (retrieval) ────┐   reduce to ~1,000
  │  • embedding similarity (two-tower ANN) │
  │  • trending in region / language        │
  │  • followed creators                    │
  │  • exploration: fresh, under-served     │
  └──────────────────┬──────────────────────┘
                     │
  ┌─── RANKING ──────▼──────────────────────┐   score each candidate
  │  predict: watch %, replay, like,        │
  │  comment, share, follow, skip           │
  └──────────────────┬──────────────────────┘
                     │
  ┌─── RE-RANKING ───▼──────────────────────┐   diversity, freshness,
  │  no creator twice in a row, safety      │   policy filters
  └──────────────────┬──────────────────────┘
                     ▼
              queue of ~30 videos, cached per user

Two-stage retrieval-then-ranking is the standard architecture and worth naming explicitly: cheap approximate nearest-neighbour search over embeddings narrows billions to about a thousand, then an expensive model scores only those.

The signals are what make TikTok specific. Watch percentage and replays are far stronger signals than likes, because they are passive and unfaked — the user does not have to decide to give them. Skips are equally informative negatives. This is why the system converges on your taste so quickly.

Instant playback

The product requirement that shapes the serving path:

1. Client holds a queue of the next ~10 recommended video ids
2. It PREFETCHES the first few seconds of the next 3-5 videos
3. Swipe → playback starts from local buffer, zero network wait
4. As the queue drains, request more; the model has already scored them

Prefetching is what makes the scroll feel instant, and it costs real bandwidth on videos that are never watched — an explicit trade the design accepts.

Short videos help enormously: a 15-second clip at moderate bitrate is a couple of megabytes, small enough to prefetch several at once and to cache aggressively at the CDN edge. That is a genuine architectural advantage over long-form video.

Storage and serving

videos       video_id, creator_id, music_id, caption, hashtags,
             duration, renditions{}, created_at
interactions user_id, video_id, watch_ms, completed, liked, shared, ts
embeddings   video_id → vector    (vector index for retrieval)
             user_id  → vector

The interactions table is the largest thing in the system — hundreds of billions of rows a day — and it is append-only. Stream it to Kafka, land it in a columnar store, and use it to retrain models. Do not write it to the serving database.

Video files go to blob storage and a CDN, with a transcoding pipeline like YouTube's but much cheaper per item because the clips are short.

The cold start problems

Both directions, and interviewers ask about both:

• New user — no history. Serve broadly popular, high-quality content, and treat the

first session as exploration: the model learns more from ten skips than from a filled-in interests form.

• New video — no engagement data. Show it to a small test audience; if watch-through is

strong, expand exponentially. This staged rollout is why virality is achievable from zero followers, and it is the mechanism worth describing.

Follow-ups to expect

• Exploration vs exploitation — a feed that only exploits known preferences collapses

into a narrow loop; a fraction of slots must be exploratory.

• Filter bubbles and safety — diversity injection and policy filters at the re-ranking

stage.

• Moderation — classifiers before wide distribution, human review for the borderline

cases, and a bias toward limiting reach rather than deleting.

• Model freshness — near-real-time feature updates so within-session behaviour changes

the next recommendations.

• Music licensing — a sound library with usage rights, and the same clip attached to

millions of videos.

Track this problem on the System Design sheet.