Short-video feed (TikTok)

01 · CONTEXT AND REQUIREMENTS

An endless feed, assembled for each person

TikTok's short-video feed is called For You. According to TikTok itself, it is powered by a recommendation system that delivers to each user the content most likely to interest them, and there is no single feed: each person gets their own feed.

When practicing this case, it is worth confirming three requirements with the interviewer: the feed opens fast, scrolling does not wait for the next video, and the system learns from user behavior. The case brings together recommendation, CDN delivery and a real-time data pipeline, and each requirement pulls on one of these parts.

The Monolith paper, from ByteDance, cites short-video ranking and online ads as businesses driven by time-sensitive customer feedback, and states that a scalable, real-time recommendation system is vital for them.

02 · WHAT FEEDS THE RANKING

Signals, weights, and what does not count directly

Among the factors TikTok lists for recommending are three groups: user interactions (liking or sharing videos, following accounts, commenting, and creating content), video information (captions, sounds, and hashtags), and device and account settings (language, country, and device type).

The factors are weighted. A strong indicator of interest, such as watching a long video from start to finish, weighs more than a weak one, such as viewer and creator being in the same country. Then the videos are ranked by probability of interest and delivered to each user's feed.

According to TikTok, neither follower count nor the account's past performance are direct factors in the recommendation.

03 · HIGH-LEVEL DESIGN

From scrolling to the list of videos

The design below is a study simplification, not TikTok's internal architecture. It separates two paths: each user's list of videos, assembled by the feed service, and the video files, delivered by a CDN.

1. The app asks for more videos when it opens or scrolls the feed, and the gateway forwards the request to the feed service.

2. The feed service checks the cache and, if there is an ordered list for that user, returns that list.

3. With no ready list, the feed service asks the ranking, which reads the metadata of the candidate videos, such as caption, sound, and hashtags, and orders them by probability of interest.

4. The app receives the list with the video addresses; the video bytes do not pass through the feed service and follow another path.

5. The CDN responds with the copy closest to the user and goes to storage only when it does not yet have the file.

04 · DELIVERING THE VIDEO

Large files, close to the viewer

A CDN is a network of interconnected servers. According to AWS, when the user is far from the origin server, a large file such as a video takes a long time to load; so the content is stored on CDN servers geographically closer to users, and the main goal is to reduce latency.

The CDN cache mechanism, for static content, works like this: on the first request, the origin responds to the visitor and at the same time sends a copy to the nearest POP; on the next request, from the same visitor or another in the same region, the cache server responds, not the origin. The POP keeps that copy as a cached file. This way, the CDN can reduce the amount of data the origin has to serve.

1. The first viewer in the region makes the first request for the file, and the request reaches the origin.

2. The origin responds to the viewer and, at the same time, sends a copy to the nearest POP, which stores it in cache.

3. When the second viewer in the same region requests the same file, the POP responds on its own, without involving the origin.

In the HTTP protocol, a Range request asks the server for only parts of a resource, and the MDN documentation cites media players with random access among the clients for which this is useful. The server responds with status 206 Partial Content.

05 · LEARNING IN REAL TIME

Closing the loop between action and recommendation

The Monolith paper observes that the same user, interested in one topic, may change interests every minute. So the serving models need to be updated with new feedback as close to real time as possible.

In Monolith, training has two stages. In batch training, the worker reads mini-batches of examples from storage. After the model is deployed, training continues in online mode: the worker consumes real-time data and updates the training PS, which periodically synchronizes its parameters with the serving PS. A PS (parameter server) stores parameters and updates them with the gradients that the workers compute. Sparse parameters are the embedding tables; dense ones are the neural network weights.

1. The app logs user actions, such as a click or a like, into an action queue.

2. The features go into another queue, and the online joiner joins them with the action labels to produce training examples.

3. The training examples are written to a queue, and the training worker consumes them directly and updates the training PS.

4. The training PS periodically sends the serving PS only the sparse parameters that were touched, at intervals on the order of minutes.

5. The model server starts ranking with the updated parameters, and the effect reaches the user.

6. The same example queue also feeds batch training, through a job that dumps the data into HDFS.

The joiner faces two practical problems. Actions and features arrive with no guarantee of time ordering, so each request has a unique key to match one with the other. And features that wait a long time for a delayed action sit in a disk-based key-value store, queried only after the in-memory cache.

Synchronization is incremental. The serving PS cannot stop serving during the update, so Monolith sends only the touched sparse parameters, at minute-level intervals. Dense parameters change much more slowly than sparse embeddings and are updated less frequently.

The memory of the embedding tables is another bottleneck. The table would be too large for the memory of a single machine, and hashing with collisions degrades model quality as the table grows. Monolith uses a hash table based on Cuckoo hashing, which inserts new keys without colliding with existing ones, filters IDs before admitting them, and expires inactive IDs after a predefined period.

For fault tolerance, Monolith snapshots all training PSs every day. If a PS fails, a day of updates is lost, but the authors report that the performance degradation was tolerable in the experiments and summarize the result as trading system reliability for real-time learning. In the experiment with the Criteo data, higher synchronization frequency improved model quality.

06 · COLD START AND LIMITS

New user, diversity, and what the case does not cover

For a new user, TikTok invites them to choose interest categories, such as pets or travel, to tune the first recommendations. Those who do not choose start with a general feed of popular videos, and their first likes, comments, and replays kick off the next recommendations.

There are also diversity and eligibility rules. The feed generally does not show two videos in a row with the same sound or from the same creator, and does not recommend duplicate content, content already seen, or content considered spam. Newly uploaded videos or videos under review, as well as spam, may be ineligible for recommendation. TikTok also says that occasionally showing a video unrelated to the stated interests is an intentional component of its approach.