Everyone has felt it. You open TikTok, watch four videos, and the fifth is somehow exactly your thing. It feels like the app read your mind. It did not. It read your behaviour, and it did it with a ranking pipeline that runs in under a second. Here is how I would build that feed if it landed on my desk, and how I would talk through it in an interview.
Start with the requirement that shapes everything: the feed has to feel instant and infinite, and it has to get better the longer you scroll. That means two things technically. Reads dominate writes by a massive margin, and personalisation has to update within a session, not overnight.
The first thing to nail down is signals. Every interaction is an event: video watched, watch duration, finished or not, rewatched, liked, shared, commented, followed the creator, and how fast you swiped away. That last one matters more than people expect. A fast swipe-away is a strong negative signal, often stronger than a like is positive. All of these events stream into a pipeline, usually through something like Kafka, because the write volume is enormous and you never want to lose signals behind a slow database.
Next is the ranking pipeline itself, and the key idea is that you do not score millions of videos per request. You do it in two stages. Stage one is candidate generation: cheaply pull a few thousand videos this user might like, from sources like their recent interests, creators they engage with, videos similar to ones they finished, and a slice of fresh content. Stage two is ranking: a heavier model scores that shortlist and orders the top handful the user actually sees. Two stages exist purely for latency. Full scoring over the whole catalog per scroll would never hit the time budget.
Then there is the cold-start problem, both for new users and new videos. For a new user you lean on popularity and coarse signals until you learn them, which happens within a few videos. For a new video you give it a small test exposure to a slice of users, measure early watch-time, and if it performs you push it wider. This is why a brand new account can occasionally go viral: the system is designed to test and promote fresh content, not just replay proven hits.
Now the serving path, where the latency budget is brutal. When you request the next batch, you cannot run the whole pipeline synchronously. So you precompute. A background process keeps a ranked, ready-to-serve queue of videos per active user, refreshed as new signals arrive. The request handler mostly reads from that cache and returns the next slice. The video bytes themselves never come from your servers directly; they come from a CDN close to the user, because a feed that ranks perfectly but buffers is a failed feed.
A few trade-offs I would raise before the interviewer asks. Freshness versus cost: recomputing candidates constantly is expensive, so you tune how often per user based on how active they are. Consistency: the feed is fine being eventually consistent, a signal from three seconds ago not being reflected yet is invisible to the user, and that relaxation is what lets the whole thing scale. Diversity: pure engagement optimisation collapses into a monotonous feed, so you inject variety on purpose. And feedback loops: if you only ever show what the model already likes, you never learn, which is why the small random exploration slice is not optional.
The mistake I see in interviews is jumping straight to the machine learning model. The model is real, but the system design points are the event pipeline, the two-stage candidate-then-rank split, the precomputed serving cache, and the CDN. Get those four right and you have described something that works at TikTok's scale. The ranking model is the last ten percent, not the first.
If you want the full version with the component diagram and the data stores laid out, I wrote the complete walkthrough here: https://www.systemdesign.academy/interview/design-tiktok
Top comments (0)