TikTok's For You Feed.

How Do You Learn What Someone Likes From Swipes That Last Less Than a Second?

It is a Thursday evening in October 2026 in Dubai. Aditi Menon, a pastry chef who moved from Kochi two years ago, installs TikTok for the first time. She never had it at home: the Government of India blocked TikTok, with 58 other apps, on 29 June 2020, and it has stayed blocked. Her colleagues at the bakery in Al Quoz have been telling her that half the city's dessert trends start there.

The app asks her to pick some interests. She taps Food and Travel, and the first video starts before she has put the phone down: a street vendor in Bangkok, then a dog on a skateboard, then a kunafa being pulled apart in slow motion. She watches the kunafa twice. She flicks the dance video after it away in under a second. Twenty minutes later her feed is half desserts, and three of them are from home bakers with a few hundred followers each. At 9 pm she posts her own first video, a cardamom kunafa, from an account nobody follows. By morning it has been shown to people who have never heard of her.

Two cold starts happened that evening, a new viewer and a new video from a new creator, and both were solved by the same machinery: a model that keeps training on what people do, minute by minute, while it serves them.

This is the system we'll design today.

The Interview Begins#

You're interviewing at a short-video company. The interviewer holds up a phone showing a full-screen video with a heart, a comment bubble and a share arrow down the right edge, and swipes up three times in four seconds.

Your Questions#

Functional Requirements#

Non-Functional Requirements#

Traffic Estimation#

Ranking Compute Estimation#

The Learning Loop Estimation#

Sync and Delivery Estimation#

Key Metrics Summary#

System Architecture#

%% title: Two loops, one model: serve the feed, learn from every swipe
flowchart TD
  subgraph L1["Layer 1 · Viewers and creators"]
    direction LR
    APP@{ icon: "sd:phone", label: "App<br/>plays, swipes, uploads" }
    CDN@{ icon: "sd:cdn", label: "CDN<br/>video segments, prefetch" }
  end
  subgraph L2["Layer 2 · Serving loop"]
    direction LR
    GW@{ icon: "sd:gateway", label: "API gateway<br/>feed, events" }
    FEED["Feed service<br/>retrieve, rank, rerank"]:::hot
    SESS@{ icon: "sd:cache", label: "Session features<br/>last 50 actions, seconds old" }
  end
  subgraph L3["Layer 3 · The model"]
    direction LR
    RET@{ icon: "sd:index", label: "Candidate sources<br/>embeddings, paths, fresh pool" }
    SPS["Serving parameter servers<br/>embeddings minutes old"]:::core
  end
  subgraph L4["Layer 4 · Learning loop"]
    direction LR
    LOG@{ icon: "tech:kafka", label: "Kafka<br/>actions, served features" }
    JOIN@{ icon: "tech:flink", label: "Flink joiner<br/>features + labels" }
    TRAIN["Online trainer<br/>training PS, collisionless tables"]:::core
  end
  subgraph L5["Layer 5 · Videos"]
    direction LR
    UP["Upload and transcode<br/>renditions, safety scan"]:::service
    OBJ@{ icon: "sd:object-storage", label: "Video store<br/>renditions, history" }
  end
  APP ==> CDN
  APP ==> GW ==> FEED
  FEED --> SESS
  FEED --> RET
  FEED --> SPS
  GW -->|"swipes, taps"| LOG
  FEED -->|"features served"| LOG
  LOG -.-> SESS
  LOG ==> JOIN ==> TRAIN
  TRAIN -.->|"touched rows, every minute"| SPS
  APP --> UP --> OBJ --> CDN
  UP -.->|"eligible videos"| RET
  class APP client
  class CDN,GW edge
  class SESS cache
  class RET store
  class LOG queue
  class JOIN service
  class OBJ store

KEY INSIGHTS:

• Three clocks. The session changes the next page in seconds (features, not weights); online training changes the embeddings in minutes; the dense network changes daily. Each fast clock covers what the slower one can't yet know
• Log what you served, don't recompute it. The feature values used to rank a video are logged at serving time and joined with the labels later, so training sees exactly what serving saw
• The model is a sparse key-value store. Most of its terabytes are embedding rows keyed by user, video, creator, sound and hashtag IDs; new IDs arrive constantly and old ones go idle. It's sharded and synced like a database, not loaded like a file

Data Flow: Aditi's Replay, Skip and Next Page#

%% title: From a replay and a skip to a changed feed and a changed model
sequenceDiagram
  autonumber
  participant A as Aditi's app
  participant G as Gateway
  participant F as Feed service
  participant S as Session features
  participant P as Serving PS
  participant K as Kafka
  participant J as Joiner and trainer
  A->>G: Events: kunafa looped twice, dance skipped at 0.8 s
  G->>K: Append, each with an event id
  K->>S: Session updated within seconds
  A->>G: Next page, 3 videos left, last 10 actions attached
  G->>F: Feed request r9
  F->>S: Read session features
  F->>P: Embeddings for Aditi and ~2,000 candidates
  F-->>A: 6 videos, mostly desserts, request id r9
  F->>K: Log the features used for r9
  K->>J: Join r9 features with r9 labels as they arrive
  J->>P: Touched embedding rows, next minute

MEANWHILE, IN PARALLEL:

• The app is already downloading the first second of each new video from the CDN, so the swipe after the buffer runs out is instant
• Each impression in r9 becomes a training example when its labels settle, and is also dumped to a batch store for retraining

Deep Dive 1: Signals: Turning a Swipe Into a Label (Week 8 Concepts: Event Ingestion; Week 2: Idempotency)#

This builds on Week 8, Day 1 · Event Ingestion at Scale and Week 2, Day 2 · Idempotency in Practice.

What is published: TikTok wrote in June 2020 that signals are "weighted based on their value to a user": finishing a longer video is "a strong indicator of interest", the viewer and creator being in the same country "a weak indicator", and a new user's "first set of likes, comments, and replays" starts the early recommendations. Its help centre lists content you "like, share, comment on, and watch in full or skip". "Not interested" lets a viewer, in TikTok's December 2021 words, "automatically skip future videos from that same creator or using the same audio". In ByteDance's Deep Retrieval production experiment (2020), on a short-video platform the paper doesn't name, labels "indicate whether a user has finished watching the video or not", and its reported metrics are video finish rate, app view time and second-day retention.

%% title: From playback events to the labels of one impression
flowchart TD
  EV@{ icon: "sd:phone", label: "Playback events<br/>impression id, sequence, position" }
  DED["Ingester<br/>keep highest sequence per impression"]:::service
  CLOSE{"Impression closed?<br/>next swipe or time-out"}
  WAIT["Keep open<br/>progress so far"]:::service
  LAB["Labels<br/>watch time, ratio, finish, loops, quick skip"]:::core
  TAP["Taps<br/>like, share, comment, follow, not interested"]:::core
  OUT@{ icon: "tech:kafka", label: "Kafka<br/>labels by impression id" }
  EV ==> DED ==> CLOSE
  CLOSE -->|"no"| WAIT
  WAIT -.-> CLOSE
  CLOSE ==>|"yes"| LAB ==> OUT
  TAP ==> OUT
  class EV client
  class OUT queue

• The impression is the unit. The feed service assigns an impression id to each video it returns; every event and tap carries it, and labels join to features by it, never by (user, video).
• Normalise by duration bucket. Keep a running percentile of watch time per duration bucket (0–10 s, 10–20 s, …) and label "watched more than typical for this length", so the model doesn't learn that long, or short, videos are simply better.
• Quick skips are labels, not noise. A skip under a threshold is an explicit negative for the video, creator, sound and topic: the main way the system learns what someone doesn't want, since few people tap "Not interested".
• Not interested is the strongest negative, and an immediate filter: the creator and sound join the session's exclusion list on the next request.
• Late taps. A follow from the creator's profile later still carries the impression id that led there; Deep Dive 2 handles the timing.

# labels/impression.py

"""
Labels for one impression from playback events (illustrative). Events carry an
impression id and a sequence number, so resends and reordering can't inflate watch
time; watch time is judged against videos of the same length.
"""

QUICK_SKIP_S = 2.0
MAX_RATIO = 3.0                         # cap loops so one stuck phone can't dominate


def close_impression(events: list, duration_s: float, typical_s_for_bucket: float) -> dict:
    latest = {}
    for e in events:                    # dedupe: keep the last state per sequence number
        latest[e["seq"]] = e
    ordered = [latest[k] for k in sorted(latest)]
    loops = sum(1 for e in ordered if e["type"] == "loop")
    last_pos = max((e["pos_s"] for e in ordered if "pos_s" in e), default=0.0)
    watched_s = loops * duration_s + last_pos
    taps = {e["type"] for e in ordered if e["type"] in ("like", "share", "comment", "follow", "not_interested")}
    return {
        "watch_s": watched_s,
        "watch_ratio": min(watched_s / duration_s, MAX_RATIO),
        "finished": loops > 0 or last_pos >= 0.95 * duration_s,
        "loops": loops,
        "quick_skip": watched_s < QUICK_SKIP_S and not taps,
        "above_typical": watched_s > typical_s_for_bucket,     # the duration-normalised label
        **{t: (t in taps) for t in ("like", "share", "comment", "follow", "not_interested")},
    }

Deep Dive 2: The Real-Time Training Loop (Week 8 Concepts: Streaming vs Batch, Late Data; Week 3: Backpressure)#

This builds on Week 8, Day 2 · Streaming vs Batch Processing, Week 8, Day 4 · Late Data and Week 3, Day 3 · Backpressure and Flow Control.

What is published: ByteDance's Monolith paper (which doesn't name TikTok) uses "one Kafka queue to log actions of users" and "another Kafka queue for features", joined by "a Flink streaming job for online feature Joiner" that "concatenates features with labels from user actions and produces training examples", written to a Kafka queue read directly by online training and dumped to HDFS for batch training. Actions and features arrive "without guarantee in time order", so each request has a unique key, and because a user may act days later, "an on-disk key-value storage is utilized to store features that are waiting for over certain time period", checked after the in-memory cache. The joiner does negative sampling, and serving applies "log odds correction" so that "the online model is an unbiased estimator of the original distribution". Batch training reads the data in "one pass", for when "we modify our model architecture and retrain the model". The open-source repository says real-time training captures "the latest hotspots".

%% title: The streaming engine: from served features and actions to examples
flowchart TD
  FEED["Feed service<br/>features served, by request key"]:::service
  APP@{ icon: "sd:phone", label: "App<br/>watch, loop, skip, taps" }
  FK@{ icon: "tech:kafka", label: "Kafka · features" }
  AK@{ icon: "tech:kafka", label: "Kafka · actions" }
  J@{ icon: "tech:flink", label: "Flink joiner<br/>in-memory cache" }
  KV@{ icon: "sd:database", label: "On-disk KV<br/>features waiting longer" }
  NS["Negative sampling<br/>keep rate r, recorded"]:::core
  EK@{ icon: "tech:kafka", label: "Kafka · training examples" }
  ON["Online trainer<br/>reads the stream"]:::core
  HD@{ icon: "sd:object-storage", label: "HDFS dump<br/>batch retraining" }
  FEED ==> FK ==> J
  APP ==> AK ==> J
  J -.->|"miss"| KV
  J ==> NS ==> EK
  EK ==> ON
  EK --> HD
  class APP client
  class FK,AK,EK queue
  class J service
  class KV,HD store

• Two clocks inside the joiner. Fast labels (watch, loop, skip, like) settle when the impression closes: emit then. Slow labels (a follow from the profile, a later share) become separate, head-specific examples whenever they arrive, up to a horizon such as a day; each head's loss counts only examples carrying its label.
• The joiner is a windowed stream join keyed by impression id: features in memory for 15 minutes (≈ 900 GB at peak, on the estimate), then on disk for a day, with a watermark per head. Labels that arrive before their features wait briefly, then drop.
• Sample negatives, then correct. For sparse heads like "like", keep each negative with probability r, record r on the example, and multiply the predicted odds by r at serving. Watch-time heads have a value for every impression: don't sample them.
• Freshness beats completeness online. If the trainer lags, read the newest data first and let the batch path pick up what was skipped.
• Batch is still there. A new architecture is trained first in one pass over weeks of HDFS dumps, then switched to the stream where the dumps end.

# joiner/join.py

"""
A windowed join of served features and labels (illustrative). Features wait in
memory, then on disk; fast labels emit an example when the impression closes, slow
labels emit head-specific examples later. Negatives are sampled with a recorded
rate and corrected at serving.
"""

import random

MEMORY_S = 15 * 60
SLOW_HEADS = ("follow", "late_share", "not_interested")


class Joiner:
    def __init__(self, kv, out, keep_negative: float = 0.1):
        self.mem, self.kv, self.out, self.r = {}, kv, out, keep_negative

    def on_features(self, key: str, feats: dict, now: float):
        self.mem[key] = (feats, now)

    def evict(self, now: float):                          # waiting longer: to disk for a day
        for key, (feats, t) in list(self.mem.items()):
            if now - t > MEMORY_S:
                self.kv.put(key, self.mem.pop(key)[0], ttl_s=86_400)

    def _features(self, key: str):
        hit = self.mem.get(key)
        return hit[0] if hit else self.kv.get(key)       # memory first, then disk

    def on_closed_impression(self, key: str, labels: dict):
        feats = self._features(key)
        if feats is None:
            return "orphan"                                # held briefly elsewhere, then dropped
        if not labels["like"] and random.random() > self.r:
            labels = {**labels, "like": None}              # like head skips this example
        self.out.send({"key": key, "features": feats, "labels": labels, "keep_rate": self.r})

    def on_slow_label(self, key: str, head: str, value: bool):
        feats = self._features(key)
        if feats is not None and head in SLOW_HEADS:
            self.out.send({"key": key, "features": feats, "labels": {head: value}, "keep_rate": 1.0})


def corrected(p_sampled: float, keep_rate: float) -> float:
    """Log odds correction: undo the inflation from keeping only a fraction of negatives."""
    odds = p_sampled / (1 - p_sampled) * keep_rate
    return odds / (1 + odds)

Deep Dive 3: Collisionless Embedding Tables (Week 1 Concepts: Partitioning, Hot Keys)#

This builds on Week 1, Day 1 · Partitioning Deep-Dive and Week 1, Day 4 · Hot Keys and Skew.

What is published: In ByteDance's Monolith paper (which doesn't name TikTok), a first principle is "to avoid cramping information from different IDs into the same fixed-size embedding". Its HashTable uses a cuckoo hashmap, "which supports inserting new keys without colliding with existing ones", with worst-case O(1) lookups. Because "popular IDs may occur millions of times while the unpopular ones appear no more than ten times", and stale IDs such as "a short-video that is out-of-date" rarely help, IDs are admitted only after a per-model occurrence threshold plus "a probabilistic filter", and "set to expire after being inactive for a predefined period of time", tunable per table. Hashing MovieLens IDs into a smaller space collided 7.73% of user IDs and 2.86% of movie IDs, and the collisionless model had higher AUC from the first epoch; on a production model with "around 1000 embedding tables", whose baseline compressed a 2⁴⁸ ID space into 2²⁵ rows, the collisionless table scored higher online AUC over the days measured. Parameters live on parameter servers in TensorFlow's worker and parameter-server setting.

%% title: The life of one ID in a collisionless table
stateDiagram-v2
  [*] --> UNSEEN
  UNSEEN --> COUNTING: first occurrence
  COUNTING --> COUNTING: seen again, below threshold
  COUNTING --> ADMITTED: threshold reached, cuckoo insert
  ADMITTED --> ADMITTED: trained, synced to serving
  ADMITTED --> IDLE: no examples for a while
  IDLE --> ADMITTED: seen again
  IDLE --> EXPIRED: table's expiry passed
  EXPIRED --> COUNTING: comes back later
  COUNTING --> [*]: never reaches threshold
  class ADMITTED ok
  class EXPIRED bad
  class COUNTING queue

• Cuckoo hashing, briefly. Two arrays, two hash functions; a key lives in one of its two slots, and inserting into an occupied slot evicts the occupant to its other slot (a cycle triggers a rehash). Lookups check two places. The point isn't speed: two IDs never share a vector.
• Admission is the memory budget. With a threshold of, say, 5, a video shown three times never costs a row; until admitted, its side features (creator, sound, hashtags, duration), themselves admitted IDs, describe it.
• Expiry per table. Video rows can expire after a few idle weeks; user rows should last longer, since a person returning after two months is mostly the same person.
• Partition by (table, ID). A hash of table and ID spreads rows evenly across parameter-server shards; huge tables (users, videos) span many shards, small ones live on one.
• Hot rows are a skew problem. A viral video or trending sound is in a large share of examples: combine its gradients per worker batch before pushing, and keep an LRU of hot rows in the feed service, refreshed on each sync.

# embeddings/table.py

"""
A collisionless embedding table with admission and expiry (illustrative). Rows are
keyed by the full ID in a cuckoo-hash map; an ID earns a row only after it has been
seen enough times (counted in a count-min sketch), and loses it when idle too long.
"""

import time


class CollisionlessTable:
    def __init__(self, cuckoo_map, sketch, dim: int, admit_after: int, expire_s: float):
        self.rows, self.seen = cuckoo_map, sketch        # full 64-bit ID -> (vector, last_seen)
        self.dim, self.admit_after, self.expire_s = dim, admit_after, expire_s
        self.default = [0.0] * dim

    def lookup(self, id_: int, training: bool) -> list:
        row = self.rows.get(id_)
        if row is not None:
            self.rows.put(id_, (row[0], time.time()))
            return row[0]
        if training and self.seen.add_and_count(id_) >= self.admit_after:
            vec = [0.0] * self.dim                       # admitted: trained from here on
            self.rows.put(id_, (vec, time.time()))
            return vec
        return self.default                              # not yet: side features carry it

    def sweep(self, now: float):
        for id_, (_, last) in self.rows.items_snapshot():
            if now - last > self.expire_s:
                self.rows.delete(id_)

Deep Dive 4: From Trainer to Server: Parameter Sync and Feature Consistency (Week 5 Concepts: Consistency Models; Week 10: Deployment Strategies)#

This builds on Week 5, Day 1 · Consistency Models and Week 10, Day 3 · Deployment Strategies.

What is published: The production models in ByteDance's Monolith paper (which doesn't name TikTok) are "usually several terabytes in size"; serving must not stop, and shipping the whole model "requires doubled model size of memory". Since sparse parameters dominate the model, only a few IDs are trained in a short window, and dense variables "move much slower than sparse embeddings", it keeps "a hash set of touched keys" and pushes those rows "with a minute-level time interval", while dense parameters sync at "day-level", "when the traffic is lowest (e.g. midnight)", with "no conspicuous loss" from the mismatch. On the Criteo ads dataset, a simulated online model's average AUC was 79.66 with a 5-hour sync, 79.78 with 1 hour and 79.80 with 30 minutes, against about 79.43 for batch training; a live A/B test on a production ads model showed "a significant bump in online serving AUC". Training parameter servers are snapshotted daily: at a 0.01% daily failure rate per machine across 1,000 servers, one fails about every 10 days, which in the paper's example of 15 million daily users loses a day's feedback from 15,000 of them; "a model from the previous day works embarrassingly well".

%% title: Touched rows every minute, dense weights every night
flowchart TD
  TW["Training workers<br/>read the example stream"]:::service
  TPS["Training PS<br/>rows + optimiser state"]:::core
  TK["Touched-key set<br/>IDs updated since last sync"]:::hot
  SPS@{ icon: "sd:servers", label: "Serving PS, each region<br/>rows overwritten in place" }
  DN@{ icon: "sd:cron", label: "Dense weights<br/>daily, quietest hour" }
  SNAP@{ icon: "sd:object-storage", label: "Daily snapshot<br/>restore a failed shard" }
  FS["Feed service<br/>hot-row cache"]:::service
  TW ==> TPS
  TPS ==> TK
  TK ==>|"every minute"| SPS
  TPS -.-> DN
  DN -.-> SPS
  TPS -.-> SNAP
  SPS ==> FS
  class SPS store
  class DN service
  class SNAP store

• A sync is a stream of row upserts and deletes. Each push carries (table, ID, vector, sync sequence); expired IDs travel as deletes. Each row is replaced atomically, so a lookup gets the old vector or the new one, never half of each; a whole minute's batch needn't be atomic.
• That's a consistency model, chosen. Within a row: atomic. Across rows of one sync: eventual, within seconds. Across sparse and dense: bounded staleness of a day. Across regions: the same stream applied in order, so all converge.
• Read your own swipes. The model's minute-level sync can't promise that Aditi's next page reflects the swipe she made two seconds ago. The session can: the app attaches her last few actions to every feed request, so the newest signal never depends on the pipeline's lag.
• One definition of every feature. Features are defined once in a shared library used by the feed service; the feed service logs the values it computed; training uses the logged values. Training-serving skew is a correctness bug, not a tuning problem.
• Deploying a new model is a migration. Train it in batch over dumped examples, catch it up on the stream, serve it to a small slice beside the current one, compare finish rate, watch time and next-day return, then ramp. Rollback is cheap: the old model kept training online throughout.

# sync/delta.py

"""
Incremental parameter sync (illustrative). Training shards record which IDs they
updated; every minute only those rows go to serving, applied row by row while it
keeps serving. Dense weights go once a day, at the quietest hour.
"""


class TrainingShard:
    def __init__(self, rows, publisher):
        self.rows, self.pub = rows, publisher       # (table, id) -> (vector, optimiser_state)
        self.touched, self.seq = set(), 0

    def apply_gradient(self, key, grad, lr):
        self.rows[key] = optimiser_step(*self.rows[key], grad, lr)
        self.touched.add(key)

    def sync_sparse(self):                          # called every 60 s
        self.seq += 1
        upserts = [(k, to_fp16(self.rows[k][0])) for k in self.touched if k in self.rows]
        deletes = [k for k in self.touched if k not in self.rows]     # expired since
        self.pub.send({"seq": self.seq, "upserts": upserts, "deletes": deletes})
        self.touched.clear()


class ServingShard:
    def __init__(self):
        self.rows, self.applied_seq = {}, 0

    def on_sync(self, msg: dict):
        if msg["seq"] <= self.applied_seq:
            return                                  # a replay: already applied
        for k, vec in msg["upserts"]:
            self.rows[k] = vec                      # one atomic replace per row
        for k in msg["deletes"]:
            self.rows.pop(k, None)
        self.applied_seq = msg["seq"]

Deep Dive 5: Cold Start: New Users and New Videos (Week 4 Concepts: Caching Patterns; Week 7: Relevance)#

This builds on Week 4, Day 1 · Caching Patterns and Week 7, Day 3 · Query Processing and Relevance.

What is published: TikTok invites new users "to select categories of interest, like pets or travel", otherwise starting with "a generalized feed of popular videos", which its help centre says is "appropriate for a broad audience and influenced by your location and language settings"; then "your first set of likes, comments, and replays will initiate an early round of recommendations". "Neither follower count nor whether the account has had previous high-performing videos are direct factors", videos "that have just been uploaded or are under review" may be ineligible, and the safety team reviews videos "as they rise in popularity". ByteDance's Deep Retrieval test, on a short-video platform the paper doesn't name, found the method "more friendly to less popular videos or less popular creators". Next-User Retrieval (2025) attacks item cold start on Douyin, "a platform with over 600 million daily active users": from the sequence of users who recently engaged with a new item, it generates "the next potential user who is most likely to interact with the item", with the item's features as a prompt so that "items with no interaction can generate the first user"; it reported +0.0142% daily active users and +0.1144% publications in A/B tests and was "integrated into Douyin's main recommendation system".

%% title: A new video, from upload to the open feed
stateDiagram-v2
  [*] --> UPLOADED
  UPLOADED --> PROCESSING: transcode, fingerprint
  PROCESSING --> UNDER_REVIEW: automated scans
  UNDER_REVIEW --> REMOVED: violates guidelines
  UNDER_REVIEW --> NOT_RECOMMENDED: FYF ineligible
  UNDER_REVIEW --> TEST_POOL: eligible
  TEST_POOL --> WIDER_POOL: beats its category
  TEST_POOL --> RESTING: below its category
  WIDER_POOL --> OPEN: keeps beating it
  WIDER_POOL --> RESTING: falls off
  OPEN --> UNDER_REVIEW: rising fast, re-checked
  RESTING --> [*]
  REMOVED --> [*]
  class OPEN ok
  class REMOVED bad
  class UNDER_REVIEW queue

• New users run on features, not IDs. Until her ID is admitted, Aditi is her categories, language, country and, above all, her session; the ranker has learnt from millions of other first sessions how to read a short history.
• The seed lists are a cache. "Popular in Food, UAE, English" is the same for every new user there: compute it every few minutes, filter for broad suitability, and serve it cache-aside without touching the ranker.
• Explore on purpose in the first minutes. Spread the first pages across topics so each swipe separates hypotheses.
• New videos get a budget, not a guess. A small number of impressions with likely viewers; its rates are a Beta posterior compared with its category's prior, so promotion is a statistical decision.
• Stages, not a cliff. Small pool, larger pool, open feed: more reliable evidence and a higher safety bar at each step, with a re-review before millions.
• The video's own ID joins late. Until it's admitted (Deep Dive 3), its sound, hashtags, creator and content embedding stand in.

# coldstart/explore.py

"""
Staged exposure for new videos (illustrative). A video's "watched more than typical"
rate is a Beta posterior compared with its category's prior; it moves to a bigger
pool when it probably beats the category, and near-duplicates share one budget.
"""

import random

BUDGET = {"test": 300, "wider": 5_000}
NEXT = {"test": "wider", "wider": "review, then open"}


def p_beats(succ: int, n: int, a: float, b: float, draws: int = 2000) -> float:
    wins = sum(random.betavariate(a + succ, b + n - succ) > random.betavariate(a, b)
               for _ in range(draws))
    return wins / draws


def decide(video, stats, prior) -> str:
    if video.duplicate_of_one_already_tested:
        return "resting"
    if stats.impressions < BUDGET[video.stage]:
        return video.stage                          # still collecting evidence
    p = p_beats(stats.above_typical, stats.impressions, *prior[video.category])
    if p >= 0.8:
        return NEXT[video.stage]
    return "resting" if p < 0.3 else video.stage

Deep Dive 6: Serving the Feed: Funnel, Diversity, Safety and Instant Playback (Week 4 Concepts: Multi-Tier Caching, Thundering Herd; Week 10: Capacity Planning)#

This builds on Week 4, Day 5 · Multi-Tier Caching, Week 4, Day 3 · Thundering Herd and Week 10, Day 4 · Capacity Planning.

What is published: ByteDance's Deep Retrieval paper, about a short-video platform it doesn't name, says "fine ranking usually handles only hundreds of items for each user request" and "multiple candidate generation sources are used at the same time to produce a diverse set of candidates"; rebuilding its learnt structure over all items takes "about 10 minutes" on CPUs. TikTok's feed "generally won't show two videos in a row made with the same sound or by the same creator", and skips "duplicated content, content you've already seen before, or any content that's considered spam". Its For You feed eligibility standards (August 2025; the August 2026 update keeps the wording) aim "to prevent our systems from repeatedly recommending content that could lead to a negative experience, such as extreme fitness or dieting, sexual suggestiveness, sadness, or overgeneralized mental health advice", and note that videos left out may still be found through search or the creator's account. As shown on TikTok's Transparency Center in October 2026, 97%+ of violative video removals were automated, 99%+ of violative content removed was taken down before anyone reported it, and 96%+ of user-flagged violative videos were removed in under 2 hours. TikTok hasn't published how it stores, transcodes or delivers video; Bonus Problem 19 (YouTube) covers that pipeline.

%% title: One feed request, from sources to a playable page
flowchart TD
  REQ@{ icon: "sd:phone", label: "Feed request<br/>3 buffered, last 10 actions" }
  SRC["Candidate sources, in parallel<br/>embedding ANN · learnt paths · follows · fresh · explore"]:::service
  FIL["Filters<br/>seen, blocked, ineligible, not interested"]:::service
  PRE@{ icon: "sd:ml", label: "Pre-ranker<br/>2,000 to 300" }
  RANK@{ icon: "sd:ml", label: "Multi-task ranker<br/>watch, finish, loop, like, follow, skip" }
  RR["Re-rank<br/>creator, sound, theme limits, explore slot"]:::hot
  PAGE@{ icon: "sd:feed", label: "Page of 6<br/>impression ids, logged features" }
  CDN@{ icon: "sd:cdn", label: "CDN<br/>first second prefetched" }
  REQ ==> SRC ==> FIL ==> PRE ==> RANK ==> RR ==> PAGE ==> CDN
  class REQ client
  class PRE,RANK service
  class PAGE service
  class CDN edge

• One value per video: a weighted sum of the predicted labels, negative on quick skip and "Not interested", with weights set by experiments on long-run outcomes such as next-day return.
• Greedy re-rank under constraints. Take the best candidate that breaks no rule given the page so far and her last videos; if nothing fits, relax the weakest rule first.
• Theme limits need a theme. Classifiers and review label each video's topic and sensitivity; a window over her recent feed caps sensitive themes across pages, which is the "clusters" problem TikTok described.
• Eligibility is a filter, not a feature. A video under review or failed isn't a low score, it's absent; removals reach filters and indexes in seconds and invalidate cached lists.
• Seen means seen. A per-user Bloom filter of recently seen video IDs is checked in the filter stage.
• Prefetch is a bandwidth bet. The first second of each buffered video costs a few hundred KB; prefetch more on Wi-Fi, less on metered or slow links, and start at a lower rendition when bandwidth is poor.
• Uploads, briefly. An upload is transcoded into a few renditions with a small first segment, fingerprinted, scanned, and only then enters the eligibility state machine; segments are served from edge, regional and origin tiers.
• Capacity follows the funnel. Ranker accelerators scale with requests × candidates (~52 million scores a second at peak, on the estimate), parameter servers with model size and lookups, the CDN with bytes watched; each gets its own forecast and headroom.

# feed/rerank.py

"""
Greedy re-ranking under diversity and safety constraints (illustrative). The ranked
list keeps its order where it can; a candidate is skipped when it would repeat the
previous creator or sound, exceed a sensitive theme's cap in the recent window, or
fill a slot reserved for exploration.
"""

THEME_CAP = {"dieting": 1, "sadness": 1}      # at most this many per window
WINDOW = 8


def rerank(ranked: list, recent: list, page_size: int, explore: list) -> list:
    page, history = [], list(recent[-WINDOW:])
    explore_slot = page_size // 2                 # one slot for a new video, mid-page

    def ok(v) -> bool:
        prev = history[-1] if history else None
        if prev and (v.creator == prev.creator or v.sound == prev.sound):
            return False
        if v.theme in THEME_CAP:
            if sum(1 for h in history[-WINDOW:] if h.theme == v.theme) >= THEME_CAP[v.theme]:
                return False
        return True

    pool = list(ranked)
    while len(page) < page_size and pool:
        source = explore if len(page) == explore_slot and explore else pool
        pick = next((v for v in source if ok(v)), None)
        if pick is None:
            pick = next((v for v in pool if v.theme not in THEME_CAP), pool[0])  # relax the weakest rule
        source.remove(pick) if pick in source else pool.remove(pick)
        page.append(pick)
        history.append(pick)
    return page

Aditi's Evening#

Edge Cases#

Monitoring Dashboard#

SLOs for the Platform#

The interviewer leans back. "One more."

Summary: Concepts Applied from 10-Week Course#

Why TikTok Matters#

Self-Assessment Checklist#

After studying this case study, you should be able to:

Signals and the loop:

The model as a live store:

Cold start, serving and safety:

Sources#

TikTok:

• Talk

  TikTok Newsroom — How TikTok recommends videos #ForYou (signals and their weighting; finishing a longer video as a strong indicator; follower count not a direct factor; new users' categories or popular videos; first likes, comments and replays; no two in a row with the same sound or creator; just-uploaded or under-review videos may be ineligible), 18 June 2020: https://newsroom.tiktok.com/en-us/how-tiktok-recommends-videos-for-you

• Talk

  TikTok Newsroom — An update on our work to safeguard and diversify recommendations (series of similar content "problematic if viewed in clusters"; "Not interested"; review of videos as they rise in popularity), 16 December 2021: https://newsroom.tiktok.com/en-us/an-update-on-our-work-to-safeguard-and-diversify-recommendations

• Talk

  TikTok Newsroom — Learn why a video is recommended For You ("Why this video" reasons), 20 December 2022: https://newsroom.tiktok.com/en-us/learn-why-a-video-is-recommended-for-you

• Read

  TikTok Newsroom — Thanks a billion! (more than 1 billion people a month), 27 September 2021: https://newsroom.tiktok.com/en-us/1-billion-people-on-tiktok

• Book

  TikTok Help Center — How TikTok recommends content (like, share, comment, watch in full or skip; time spent watching weighted more heavily; first feed of broadly suitable popular content by location and language): https://support.tiktok.com/en/using-tiktok/exploring-videos/how-tiktok-recommends-content

• Docs

  TikTok Community Guidelines — For You feed Eligibility Standards (version released 14 August 2025, effective 13 September 2025; themes not to recommend repeatedly; interrupting repetitive recommendations in crisis or unrest; still findable through search or the creator's account), archived 11 July 2026: https://web.archive.org/web/20260711083758/https://www.tiktok.com/safety/en/policies-and-engagement/fyf-standards (the August 2026 update, released 25 August 2026 and effective 24 September 2026, keeps this wording; archived 6 October 2026: https://web.archive.org/web/20261006162515/https://www.tiktok.com/safety/en/policies-and-engagement/fyf-standards)

• Talk

  TikTok Transparency Center — "Measuring our efforts" headline figures, undated on the page and quoted here as shown in October 2026 (97%+ of violative video removals automated; 99%+ of violative content removed before anyone reported it; 96%+ of user-flagged violative videos removed in under 2 hours), archived 15 October 2026: https://web.archive.org/web/20261015051401/https://www.tiktok.com/safety/en/transparency/community-guidelines-enforcement-2025-4

• Read

  TikTok India — notice to users (on 29 June 2020 the Government of India decided to block 59 apps, including TikTok): https://www.tiktok.com/in/

ByteDance research:

• Paper

  Zhuoran Liu, Leqi Zou, Xuan Zou, Caihua Wang, Biao Zhang, Da Tang, Bolin Zhu, Yijie Zhu, Peng Wu, Ke Wang and Youlong Cheng — Monolith: Real Time Recommendation System With Collisionless Embedding Table (cuckoo-hash tables with occurrence filters and expiry; Kafka, Flink joiner, in-memory cache and on-disk KV; negative sampling and log odds correction; several-terabyte models; minute-level sparse and day-level dense sync; daily snapshots; MovieLens, production and Criteo results; landed in BytePlus Recommend), ORSUM workshop at ACM RecSys 2022, arXiv:2209.07663, September 2022: https://arxiv.org/abs/2209.07663

• Read

  ByteDance — Monolith source code and README ("real time training captures the latest hotspots"): https://github.com/bytedance/monolith

• Paper

  Weihao Gao, Xiangjun Fan, Chong Wang and others — Deep Retrieval: Learning A Retrievable Structure for Large-Scale Recommendations (ByteDance; hundreds of millions of users and short videos; finish-watching labels; multiple candidate sources, fine ranking of hundreds; A/B finish rate +3.0%; friendlier to less popular videos and creators; structure built in about 10 minutes), arXiv:2007.07203, July 2020: https://arxiv.org/abs/2007.07203

• Paper

  Yu-Ting Lan, Yang Huo, Yi Shen, Xiao Yang and Zuotao Liu — Next-User Retrieval: Enhancing Cold-Start Recommendations via Generative Next-User Modeling (ByteDance; item cold start on Douyin, over 600 million daily active users; +0.0142% DAU, +0.1144% publications; in Douyin's main recommendation system), arXiv:2506.15267, June 2025: https://arxiv.org/abs/2506.15267

Reporting:

• Read

  Simon Sharwood — Oracle, Michael Dell, named as investors in JV that will run TikTok's US operations (TikTok USDS Joint Venture LLC; will "retrain, test, and update the content recommendation algorithm on U.S. user data", secured in Oracle's U.S. cloud environment), The Register, 23 January 2026: https://www.theregister.com/2026/01/23/jv_announces_tiktok_us_acquisition/

Design note: the architecture, code, thresholds, dashboards and every number labelled as an assumption or estimate are an illustrative design for the problem, not a description of TikTok's internal systems. ByteDance's papers describe its research and production systems without saying which run inside the TikTok app; Next-User Retrieval was tested on Douyin, a separate app. Daily users, watch time, upload volume, request and event rates, candidate counts, table sizes, sync volumes, stage budgets, the dashboard and the final challenge's figures are assumptions.

Further Reading#

Related systems to study:

• Read

  Instagram Feed and Stories (Bonus Problem 21 in this series): a follower feed with fan-out on write and staged ranking

• Talk

  YouTube (Bonus Problem 19): uploads, transcoding, view counting and two-stage recommendations at 100 ms

• Read

  Spotify (Bonus Problem 7): recommendations and streaming for audio

Foundational concepts (this course):

• Read

  Week 1, Day 1 — Partitioning Deep-Dive

• Read

  Week 1, Day 4 — Hot Keys and Skew

• Read

  Week 2, Day 2 — Idempotency in Practice

• Read

  Week 3, Day 3 — Backpressure and Flow Control

• Read

  Week 4, Day 1 — Caching Patterns

• Read

  Week 4, Day 3 — Thundering Herd

• Read

  Week 4, Day 5 — Multi-Tier Caching

• Read

  Week 5, Day 1 — Consistency Models

• Read

  Week 7, Day 3 — Query Processing and Relevance

• Read

  Week 8, Day 1 — Event Ingestion at Scale

• Read

  Week 8, Day 2 — Streaming vs Batch Processing

• Read

  Week 8, Day 4 — Late Data

• Read

  Week 10, Day 3 — Deployment Strategies

• Read

  Week 10, Day 4 — Capacity Planning

"Learn from the session in seconds, from everyone in minutes, and from the past once a day."