TikTok

Assume 500M daily active users. Each active user watches or starts 120 videos per day on average, so the platform serves about 60B video plays per day. A feed page returns 20 ranked items. Each play emits about 4 engagement events on average, such as impression, start, progress or completion, and an optional action.

Assume 20M video uploads per day. The average original upload is 80 MB, and transcoded adaptive bitrate renditions plus thumbnails and metadata average 200 MB per accepted video. Assume 70 percent of uploads pass initial moderation and become eligible for recommendation. Average delivered bytes per play are 5 MB because many short videos are watched partially and ABR selects mobile-friendly bitrates.

Use a 4x peak multiplier for feed and playback traffic because usage is globally distributed but still has regional peaks. Use a 3x replication and overhead factor for media storage.

• Plays: 500M daily active users times 120 video starts per day equals 60B plays per day.
• Feed requests: if each feed response carries 20 items, 60B divided by 20 equals 3B feed pages per day. 3B divided by 86,400 seconds is about 34,700 feed QPS average. With a 4x peak, plan for about 139,000 feed QPS.
• Event ingestion: 60B plays times 4 engagement events equals 240B events per day. 240B divided by 86,400 seconds is about 2.78M events per second average, with regional peaks above 10M events per second.
• CDN egress: 60B plays times 5 MB delivered equals 300B MB per day, or about 300 PB per day. 300 PB divided by 86,400 seconds is about 3.5 TB per second average egress before protocol overhead.
• Upload storage: 20M uploads times 70 percent accepted equals 14M eligible videos per day. 14M times 200 MB of renditions and thumbnails is about 2.8 PB raw per day. With 3x replication and overhead, reserve roughly 8 to 10 PB per day.
• Ranking capacity: if the ranker scores 500 candidates per feed page, 34,700 feed QPS requires about 17M candidate scores per second average. Peak can exceed 70M scores per second, so ranking must use batching, staged models, and fallback lists.

• videos.video_id is the primary point lookup for feed rendering, playback metadata, and moderation actions.
• videos.creator_id, created_at supports creator profiles and creator tooling, but should not be used to build the For You feed.
• videos.status, moderation_state, published_at supports candidate eligibility scans and backfills.
• video_variants.video_id, variant_id supports manifest assembly and repair jobs.
• recommendation_features.entity_type, entity_id, feature_version supports online feature hydration with one or a few batched lookups.

Each video belongs to one creator and has multiple ABR variants. A user profile owns preference and safety metadata. Recommendation features are denormalized and versioned because ranking cannot afford joins across transactional tables during a feed request. Raw engagement events are linked by user id, device id, session id, video id, and request id in the event log.

Use object storage for original uploads, transcoded segments, manifests, thumbnails, and perceptual hashes. Use a wide-column or KV store such as Bigtable, DynamoDB, Cassandra, or FoundationDB for video metadata and online features. Use Kafka, Pulsar, Kinesis, or Pub/Sub for engagement streams. Use a vector index or approximate nearest-neighbor service for embedding-based candidate retrieval. Use an OLAP warehouse or lakehouse for offline training, analytics, and experimentation.

The online feature store is usually split into hot memory or SSD-backed serving for low-latency features and offline parquet or warehouse tables for training. Consistency is best-effort for most recommendation features, but policy and moderation state must be strongly enforced before content is shown.

A common mistake is to design TikTok like a follower-feed system. The For You Page does not primarily fan out creator posts to followers. It selects from a massive global inventory and ranks videos for each user at request time.

Candidate generation should retrieve thousands of possible videos in tens of milliseconds. Use multiple recall channels: approximate nearest-neighbor search over user and video embeddings, regional trending videos, topic-interest buckets, fresh uploads in exploration pools, similar creators, collaborative filtering, and sponsored candidates. Each channel contributes a bounded number of candidates and metadata about why the candidate was retrieved.

The service must remove videos the user has already seen, blocked creators, unsafe content, unavailable regions, age-ineligible content, and videos that violate freshness or frequency caps. Final ranking only works if retrieval includes enough diverse high-quality options, so candidate-generation metrics should track recall, source diversity, latency, and downstream engagement.

Ranking quality depends on fresh features. User features include recent watch time by topic, skip patterns, language preference, session momentum, repeated interests, negative feedback, and social actions. Video features include completion rate, replay rate, like rate, report rate, freshness, topic embeddings, creator reputation, and moderation signals. Context features include network type, device, time of day, region, and app version.

Online ranking cannot join across transactional stores. The ranker should issue batched feature-store lookups keyed by user id, session id, video ids, and creator ids. Feature values must carry a version and freshness timestamp so models can reject stale or incompatible features.

Model serving should score candidates in batches and use staged ranking. A lightweight model can reduce thousands of candidates to hundreds, then a heavier model scores the final set. If model serving is slow, use cached scores, smaller models, or fallback ranking rather than timing out the whole feed.

TikTok's recommendation quality depends on interpreting weak and strong signals. Watch time and completion are often stronger than likes because they capture implicit interest. Replays are a high-intent signal. Skips, short watch time, reports, and not interested actions are negative signals. Shares, follows, comments, and profile visits are explicit positive signals.

The event pipeline should deduplicate client retries, sequence events by session, and compute real-time aggregates such as video velocity, topic affinity, creator affinity, fatigue, and recent negative feedback. Hot video features may need updates every few seconds because viral distribution can change quickly.

Not every signal should immediately amplify distribution. Reports and moderation risk should dampen exposure. New videos need controlled exploration so the system can estimate quality without overexposing unsafe or low-quality content. The feedback loop is therefore both a ranking asset and a safety risk.

New users have little behavioral history. Start with onboarding interests, region, language, device context, broad trending content, and short exploration sessions. After a few swipes, session-level features can dominate long-term profile assumptions because watch time and skips provide quick signal.

New videos have no engagement history. Use creator reputation, content embeddings, caption and hashtag features, audio features, visual topics, language, safety score, and similarity to known successful videos. Place each new video into small exploration buckets and expand distribution only when early cohorts show healthy completion, replay, and low negative feedback.

New creators need a fairness mechanism so established creators do not monopolize recommendations. Use quotas or calibrated exploration for new creators, but cap exposure until moderation and quality signals are reliable. Cold-start policy should be measurable through creator retention, user satisfaction, and safety incidents.

Upload should be resumable and direct to object storage so API servers do not proxy large files. After completion, workers transcode into multiple renditions for adaptive bitrate playback, create manifests, extract thumbnails, compute fingerprints, and store segment metadata. Failed variants can be retried independently.

Playback uses CDN because origin egress would be unaffordable and too slow. The feed response should include manifest URLs, thumbnail URLs, expected duration, and prefetch count. The client fetches manifests and the first segments for the next few videos while the current video plays. This turns recommendation latency and network variability into background work.

Prefetch has a cost tradeoff. Aggressive prefetch reduces swipe latency but wastes bandwidth when users skip quickly or leave the app. The client should adapt prefetch depth based on network type, battery, buffer health, and predicted session length. The server can avoid prefetching risky or low-confidence recommendations too far ahead.

Moderation is not a separate afterthought. It is part of candidate eligibility and ranking. Automated classifiers, perceptual hashes, copyright fingerprints, text analysis, audio analysis, creator history, and user reports all produce policy features. Some decisions block content globally, while others limit reach by age, region, topic, or confidence.

The system should support pre-publish checks, post-publish monitoring, human review queues, and fast takedown propagation. Ranking should downrank borderline content before final moderation confidence is reached. Reports from trusted users or high-severity categories can trigger immediate exposure reduction.

Policy decisions need auditability. Store model version, rule version, reviewer decision, reason codes, and distribution changes. This matters for user appeals, regulatory requests, and debugging why a video was or was not shown.

Alternative one is a follower-feed design similar to Instagram or Twitter. It is simpler for social subscriptions, but it misses TikTok's core discovery product and does not solve global inventory ranking.

Alternative two is a mostly offline precomputed feed. It can reduce online latency, but it reacts poorly to session behavior, fresh viral videos, and real-time safety signals.

Alternative three is a pure trending feed by region and language. It is robust and cheap, and it is useful as a fallback, but it under-personalizes and makes it harder for niche interests and new creators to find the right audience.

Do not use this architecture for a small private video app where users only watch subscriptions or team-owned content. The cost and complexity of real-time recommendation, feature stores, model serving, and massive CDN optimization are justified only when discovery quality and engagement are the primary product differentiators.