TikTok System Design Interview: The For You Feed and Its Real-Time Recommender
TikTok serves a For You feed to more than a billion monthly users, and the interesting number is not the user count but the interaction rate. Every swipe, replay, pause, like, and share becomes a training signal, so the platform ingests tens of billions of interaction events per day (estimate) and folds them back into ranking models within minutes. The hard part is not storing the videos. It is deciding, in under a couple hundred milliseconds, which handful of clips out of hundreds of millions a specific person will want to watch next.
The defining challenge of TikTok is the For You recommendation feed, not the video plumbing. A user opens the app with no explicit query and expects an endless stream of clips tuned to their taste, refreshed as their taste shifts inside a single session. The system answers this with a two-stage recommender. Candidate generation narrows hundreds of millions of videos down to a few hundred using cheap retrieval models and embedding lookups, then a heavier ranking model scores those candidates on many objectives at once, watch time, replay, like, share, comment, and follow probability. What makes the recommendations feel uncanny is freshness. ByteDance's Monolith training system updates the model online from live interaction streams rather than in nightly batches, so a signal from a video you watched a minute ago can influence what you see next. Around that core sits a conventional but very large video platform: an upload and transcoding pipeline that fans one master file into many bitrate and resolution renditions, object storage for the media, a CDN that pushes clips to edge caches near the viewer, and a client that aggressively prefetches the next few videos so the feed feels instant when you swipe.
Asked at: Asked at ByteDance, Meta, Google, Snap, Netflix, and most companies that run a personalized feed or a large recommendation surface. It also shows up at startups building short-video or discovery products.
Why this question is asked
Interviewers like this problem because it forces a candidate to reason about a recommendation system as a system, not just a model. You cannot hand-wave the machine learning and you cannot hand-wave the serving path either. A strong answer connects the two stages of retrieval and ranking to concrete latency budgets, explains how a write-heavy interaction stream feeds model training in near real time, and handles the awkward parts everyone forgets: cold-start for brand new videos and new users, feedback loops that trap users in a narrow interest, and the transcoding and CDN cost of serving billions of views. It rewards people who can hold both the offline data pipeline and the online request path in their head at once.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Serve a personalized, effectively endless For You feed with no explicit search query from the user
- Rank candidate videos by predicted engagement, weighting watch time, replays, likes, shares, comments, and follows
- Capture fine-grained interaction signals per video: watch duration, completion, replays, skips, and explicit not-interested feedback
- Support video upload with transcoding into multiple bitrates and resolutions plus thumbnail and preview generation
- Run content moderation on uploads before wide distribution
- Cold-start new videos by giving them exposure to small test audiences and promoting the ones that perform
- Prefetch and cache the next several videos on the client so swiping feels instant
- Let users follow creators, and blend followed content with algorithmic discovery
- Support creator and topic search alongside the primary discovery feed
Non-functional requirements
- Feed request latency under roughly 200ms at the tail so the next video is ready before the current one ends
- High availability for feed serving; a failed personalization call should fall back to a generic feed, never a blank screen
- Near real-time model freshness so a session's early signals shape its later recommendations
- Massive read scale for video delivery, with most bytes served from CDN edge rather than origin
- Durable storage for uploaded media with geographic redundancy
- Elastic ingestion for a write-heavy, bursty interaction event stream
- Cost efficiency on transcoding and egress, since compute and bandwidth dominate the bill at this scale
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Monthly active users
~1B+ (published, order of magnitude)
TikTok has publicly crossed a billion monthly active users. Exact current figures vary by source and are not treated as precise here.
Video views per day
Tens of billions (estimate)
Derived: if ~1B users watch even 30 to 50 short clips a day, that is 30 to 50B views daily. Short clips and long sessions push the per-user count high, so tens of billions is a conservative floor.
Interaction events per day
Hundreds of billions (Derived estimate)
Derived: each view emits several events (impression, watch-time ticks, skip or complete, plus optional like, share, comment). At tens of billions of views times roughly 5 to 10 events each, the interaction stream lands in the hundreds of billions per day.
Candidate pool per request
Hundreds of millions of eligible videos
The active corpus of recent, eligible short videos is very large. Candidate generation must cut this to a few hundred before ranking; the exact eligible-set size is an estimate.
Candidates after retrieval
~Hundreds per request
Retrieval narrows the pool to a few hundred candidates, a common published figure for two-stage recommenders, so the expensive ranking model only scores a bounded set.
Feed ranking latency budget
~100 to 200ms server side (estimate)
Derived from the product feel: the next clip must be selected, prefetched, and buffered before the current one ends, so retrieval plus ranking plus assembly needs to fit inside a couple hundred milliseconds.
High-level architecture
A request starts when the client asks for the next batch of feed items, usually well before the user reaches the end of what is already buffered. An API gateway routes the call to the feed service, which pulls the user's current feature vector and recent-session context from a low-latency feature store. Candidate generation runs first: several retrieval sources produce candidates in parallel, including embedding-based nearest-neighbor lookups against a vector index, videos from followed creators, trending and fresh content, and small exploration slots for cold-start videos. These sources merge into a few hundred candidates. The ranking service then scores each candidate with a deep model that predicts many engagement objectives at once, and a policy layer combines those predictions into a single score while applying diversity rules, de-duplication against what the user already saw, and freshness and safety filters. The ranked list goes back to the client, which immediately begins prefetching the top videos from the CDN so playback is instant on swipe. Meanwhile every interaction the user produces is emitted to an event pipeline. That stream feeds two consumers: the feature store, so the user's profile reflects what they just did, and the online training system, which updates model parameters continuously and pushes fresh embeddings and weights out to the serving models. Separately, the upload path is asynchronous. A creator uploads a master file, which lands in object storage, kicks off transcoding into a ladder of renditions, runs through moderation, and once cleared becomes eligible in the candidate corpus.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Feed / recommendation service
The orchestrator for a feed request. It fetches user features, fans out to candidate sources, invokes ranking, applies business and diversity policy, and returns the ordered list. It owns the latency budget and the fallback to a generic feed when personalization is slow or unavailable.
Candidate generation (retrieval)
Cheap models and indexes that reduce hundreds of millions of videos to a few hundred. This includes an approximate nearest-neighbor index over user and item embeddings, plus rule-based sources for followed creators, trending content, and exploration slots for new videos.
Ranking service
A multi-task deep neural network with shared lower layers and separate heads that predict watch time, like, share, comment, follow, and not-interested probabilities. A scoring policy blends these heads into one ranking score. This stage is the compute-heavy part of the request and only runs on the retrieved candidates.
Online training system (Monolith-style)
Consumes the live interaction stream and updates model parameters continuously rather than in nightly batches. It uses a collisionless embedding table so high-frequency IDs get their own slots, and it streams fresh parameters to the serving models so recent behavior influences ranking within minutes.
Interaction event pipeline
A high-throughput ingestion layer, typically a partitioned log like Kafka, that captures every impression, watch-time tick, skip, and engagement action. It fans out to real-time consumers for training and feature updates and to batch storage for offline analytics and model retraining.
Video upload and transcoding pipeline
Handles chunked upload of the master file, transcodes it into a ladder of bitrate and resolution renditions with a distributed worker fleet, generates thumbnails and preview frames, and segments each rendition for adaptive streaming. Moderation runs in this pipeline before a video goes wide.
Storage and CDN delivery
Media segments live in object storage as the origin and are pushed to a global CDN so most views are served from an edge cache near the viewer. Metadata and interaction counters live in sharded databases and caches tuned for the read and write patterns of each.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
videosvideo_idcreator_idcreated_atduration_msstatusmoderation_stateCore metadata for each clip. status tracks the transcoding and eligibility lifecycle; moderation_state gates distribution. Sharded by video_id.
video_renditionsvideo_idrendition_idresolutionbitratecodecsegment_manifest_urlOne row per transcoded quality level. The manifest URL points the adaptive player at the segment list on the CDN. Read-heavy and cacheable.
user_profileuser_idembedding_vectorrecent_interactionsinterest_tagsupdated_atServing-time feature snapshot for a user. Updated in near real time from the interaction stream so session behavior is reflected in the next request.
interactionsuser_idvideo_idevent_typewatch_time_msevent_tsThe append-only interaction firehose. Written at extreme volume, partitioned by time and user; consumed by training, feature updates, and analytics. Not a random-access store.
video_embeddingsvideo_idembedding_vectormodel_versionupdated_atItem vectors backing the ANN retrieval index. Regenerated as content models change; served from an in-memory vector index for candidate generation.
video_statsvideo_idview_countlike_countshare_countcompletion_rateAggregated counters, updated by stream processing over the interaction log. Used for trending signals and cold-start promotion decisions. Eventually consistent.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Two-stage retrieval and ranking
You cannot run a heavy neural network over hundreds of millions of videos per request, so the system splits the work. Candidate generation is optimized for recall and speed: it uses embedding nearest-neighbor search plus a few rule-based sources to pull a few hundred plausible videos out of the corpus in a few milliseconds. Ranking is optimized for precision: it runs a large multi-task model over just those candidates and predicts several engagement objectives at once. The reason this split matters in an interview is the cost math. Ranking is expensive per item, so bounding the candidate set to the low hundreds is what makes the latency budget achievable. A good answer also notes that retrieval quality caps the whole system; if a great video never makes it into the candidate set, no ranking model can recover it.
Multi-objective ranking and watch time
The ranking model does not optimize a single label. It has a shared backbone and separate heads predicting watch time, completion, replay, like, share, comment, follow, and negative signals like not-interested. Watch time and completion tend to dominate because they are dense and available on every view, while likes and shares are sparse but strong. The scoring policy combines the heads with tunable weights, which is also where the platform injects goals beyond raw engagement, for example capping how much of one topic a session can contain, or protecting new creators. Interviewers probe here because naive optimization on watch time alone leads to clickbait and doom-scrolling regret, so you want to talk about balancing objectives and adding guardrails rather than chasing one metric.
Online training and model freshness
The feature that makes TikTok's feed feel different is speed of adaptation. ByteDance's Monolith system was built specifically for online training, where the model consumes the live interaction stream and updates parameters continuously instead of retraining nightly. A signal from a video you watched minutes ago can shift what you see next in the same session. The engineering challenge is that recommendation models have enormous sparse embedding tables keyed by user and video IDs, and those IDs churn constantly. Monolith uses a collisionless embedding table, backed by cuckoo hashing, so high-frequency IDs get unique slots instead of colliding through a fixed hash, plus expirable embeddings and frequency filtering to keep memory bounded. Parameters are synced from the training side to the serving side on a short cycle. The paper is candid that online training trades some system reliability for freshness, which is the kind of honest tradeoff interviewers want you to name.
Cold-start for new videos and new users
A brand new video has no interaction history, so the ranker has nothing to score it on. The platform solves this with controlled exploration. New uploads get seeded to a small test audience, and the system watches early signals like completion rate and share rate normalized for that small exposure. Videos that perform get progressively larger audiences; videos that do not quietly fade. Content-based features help too: creator history, audio track, captions, and video embeddings give a prior before behavioral data exists. New users are the mirror problem. With no history, the feed leans on popular and broadly appealing content plus fast exploration, then narrows quickly as the first few swipes reveal preferences. This is why the first session matters so much and why exploration slots are a permanent part of candidate generation, not just an onboarding hack.
The interaction event pipeline
This is the write-heavy heart of the system and the part most candidates underweight. Every impression and every watch-time tick is an event, so the volume dwarfs the number of videos or users. The pipeline is a partitioned append-only log, typically Kafka-style, that decouples producers from consumers. Real-time stream processors compute rolling features and trending counters and push them to the feature store within seconds, while the same stream feeds the online training system and lands in a data lake for offline analysis and full retraining. Key design points to raise: partitioning so a hot video or hot user does not create a skewed partition, at-least-once delivery with idempotent aggregation so counters are not corrupted by retries, and separating the low-latency path that needs freshness from the batch path that needs completeness. This is a textbook place to mention a lambda or kappa style split.
Upload, transcoding, and moderation
Upload is fully asynchronous. The client sends the master file in chunks to object storage, which emits an event that starts transcoding. A worker fleet, often GPU-backed, encodes the source into a ladder of renditions across resolutions and bitrates and segments each into short chunks for adaptive streaming, while other steps extract a thumbnail and a preview loop. Because these steps are independent, they run in parallel across a queue of jobs rather than blocking the creator. Moderation runs in the same pipeline: automated classifiers screen for policy violations before a video is eligible for wide distribution, with human review for ambiguous cases. Only after transcoding and moderation clear does the video become a candidate. Framing this as an event-driven pipeline with a message queue, decoupled workers, and a clear eligibility state machine is what separates a strong answer from someone who thinks upload is a single synchronous request.
Delivery, prefetch, and the instant-swipe feel
The feed feels instant because the client is always a few videos ahead. When the ranked list arrives, the app prefetches the first frames and low-quality segments of the next several clips from the CDN, so a swipe plays immediately and then adaptive bitrate logic upgrades quality as the buffer fills. Delivery leans hard on the CDN because segments are static and immutable, which makes them perfect for edge caching; popular clips serve almost entirely from edge with little origin load. The tension is prefetch aggressiveness versus wasted bandwidth: prefetch too little and swipes stutter, prefetch too much and you pay to download videos the user skips past. Short-video platforms tune this with adaptive preload that predicts how likely each queued video is to actually be watched and sets download priority accordingly, which is a nice concrete detail to cite.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
Two-stage retrieval plus ranking versus one big model
A single model over the full corpus per request is computationally impossible at this scale. Splitting into cheap high-recall retrieval and expensive high-precision ranking bounds the per-request cost, at the price of retrieval becoming a hard ceiling on what ranking can surface.
Online training versus nightly batch training
Online training gives the freshness that makes recommendations adapt within a session, which is a real product edge. The cost is a more complex, less reliable training system, since streaming parameter updates and continuous checkpoints are harder to operate than a clean batch job.
Optimizing watch time versus broader engagement and health
Watch time is dense and easy to optimize but rewards addictive and clickbait content and creates feedback loops. Adding likes, shares, diversity rules, and explicit negative feedback into the objective produces a healthier feed at the cost of a more complex, harder-to-tune scoring policy.
Collisionless embedding table versus fixed-size hashed embeddings
A fixed hash space is memory-bounded but forces distinct IDs to share slots, which hurts accuracy as the ID space grows. A collisionless table with expiry preserves quality for high-frequency IDs, at the cost of more memory management and a more sophisticated storage layer.
Aggressive prefetch versus bandwidth cost
Prefetching several videos ahead makes swiping feel instant but wastes egress on clips the user skips. Predictive preload that ranks download priority by likelihood of being watched is the compromise, trading extra model complexity for lower wasted bandwidth.
Exploration slots versus pure exploitation
Always showing the highest-scoring known content maximizes short-term engagement but starves new videos and traps users in a narrow interest. Reserving exploration slots solves cold-start and keeps the feed fresh, at a small, deliberate cost to immediate engagement metrics.
How TikTok actually does it
The most concrete public source on TikTok's recommender is ByteDance's own Monolith paper, which describes a production system built for online training with a collisionless embedding table using cuckoo hashing, expirable embeddings, and frequency filtering, deployed for short-video ranking and ads. The company also open-sourced a version of Monolith on GitHub. The two-stage retrieval-and-ranking structure and the multi-task ranking model that predicts watch time, like, share, comment, and follow probabilities are widely described in engineering breakdowns of the For You feed, though the exact production weights and features are not public. On the delivery side, the general short-video pattern of transcoding into an adaptive bitrate ladder, serving immutable segments from CDN edge, and using predictive preload to prefetch the next clips is well documented in the streaming and CDN literature, including recent research on pan-CDN resource adaptation for short video. Where internal details are not published, treat the above as sound general approaches rather than confirmed TikTok specifics.
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Related system design interview questions
Practice these next. They lean on the same core building blocks as TikTok.