System design interview guide
TikTok System Design Interview: The For You Feed and Its Real-Time Recommender
Short answer
TikTok system design is mostly about the For You feed. Candidate generation cuts hundreds of millions of videos down to a few hundred, and a ranking model scores those on watch time, likes, shares and follows. ByteDance's Monolith system trains the model online from live interactions, so a video you watched minutes ago can change what you see next. Around that sits a video platform: transcoding into many quality levels, a CDN, and a client that prefetches the next few videos.
Two courses by the author of this page:
770 lessons · 18 free to read
₹499 in India · $49 elsewhere, once
Get System DesignYou own this course
206 lessons · 10 free to read
₹999 in India · $49 elsewhere, once
Get AI EngineeringYou own this course
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.
Where it shows up
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.
Spec sheetTikTok
- 01Monthly active users
- ~1B+ (published, order of magnitude)
- 02Video views per day
- Tens of billions (estimate)
- 03Interaction events per day
- Hundreds of billions (Derived estimate)
- 04Candidate pool per request
- Hundreds of millions of eligible videos
worked through below, with the maths
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.
This page is the free part.
The course goes deeper on the TikTok design
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers the TikTok design across a run of lessons, not one page. These 4 alone are about 106 minutes of step-by-step reading, every one with a quiz.
- Content Delivery Network (CDN)
A CDN is thousands of caches you do not operate, and the cache key decides everything about whether it helps you.
- Prefetching
Prefetching one page ahead took the p95 from 151 ms to 124. Two pages ahead took it to 991, with the same hit rate, because a prefetch is a real request in a shared queue.
- Stream Processing
Process data as it arrives, real-time analytics, fraud detection, and event-driven architectures.
- Real-Time Analytics
How real-time analytics engines query fresh data in under a second. Shows how Pinot ingests from Kafka and compares Druid, ClickHouse and Rockset.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
The concepts were explained in a clear and structured way, with practical examples that made even complex system design topics easier to understand. I especially liked the focus on real-world architecture, scalability, trade-offs. The content was well designed, engaging, and highly useful for anyone looking to strengthen their system design skills. Highly recommended for software engineers preparing for system design interviews or wanting to build a stronger foundation in designing scalable systems.
You own this course
Continue with Content Delivery Network (CDN)pay once,
yours for life
Live from the course bench
Before you design TikTok, try the questions it rests on.
Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.
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.
Free PDF · 18 pages
Get the free System Design Interview Cheat Sheet
The interview in seven stages, the numbers worth knowing by heart, and twelve classic systems on one page each, every line linked to the lesson it comes from.
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.
Frequently asked questions
Go deeper
This guide is built on these 5 lessons. Each one teaches one piece of the TikTok design above, step by step.
- Content Delivery Network (CDN)System Design · load balancing proxies · 26 min
- PrefetchingSystem Design · caching strategies · 25 min
- Stream ProcessingSystem Design · stream batch processing · 30 min
- Real-Time AnalyticsSystem Design · stream batch processing · 25 min
- Database ShardingSystem Design · database fundamentals · 35 min
Practice with 770 system design lessons
Lifetime access for ₹499 in India or $49 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.