Design TikTok Recommendation Engine

Problem statement

Design the recommendation engine behind a TikTok-style short-video product. Every time a user opens the app or swipes near the end of their local queue, the system must assemble a personalized batch of 6-10 videos drawn from a corpus of billions of items. It must do this in under ~200 ms end to end, for hundreds of millions of concurrent users, while ingesting millions of interaction signals per second and continuously improving the models that drive ranking.

The core loop is: collect signals (watch time, completion, rewatch, like, share, follow, not-interested) → update features in near real time → retrieve hundreds of candidates from multiple recall channels → rank them with multi-objective models → re-rank for diversity, freshness, safety, and policy → deliver a prefetched batch → observe behavior → repeat. This loop closes in seconds for real-time features and in minutes to hours for model updates. A food-delivery backend retries a notification; a recommender that serves one bad batch loses the session, and a recommender that optimizes the wrong objective erodes long-term trust.

Why the problem is distinctive

First, read fan-out is extreme but latency-bound: unlike a follower feed that can precompute, the For-You style feed is ranked at request time because the most valuable signal is what the user did thirty seconds ago. Second, the write path is a high-volume telemetry stream, not transactional records: every view produces a burst of client-side events that must be batched, deduplicated, and joined into training labels. Third, the system is a cyber-ML hybrid: model freshness, feature freshness, and serving freshness are three different clocks that must stay synchronized, and any one of them can degrade independently. Fourth, the objective is contested: watch time, satisfaction, diversity, creator fairness, and safety all pull in different directions, and the architecture must make those trade-offs explicit, measurable, and governable.

Public operating baseline versus design assumptions

Public evidence establishes that this category operates at enormous scale. TikTok announced 1 billion monthly active users in September 2021 and has since reported higher figures; third-party measurement firms have estimated average daily time in the app near 90 minutes in mature markets. Alphabet reported in its Q2 2023 earnings call that YouTube Shorts was receiving roughly 70 billion daily views. Meta has publicly described Reels as its fastest-growing content format and published a multi-stage description of Reels ranking. These are cited public figures for context, not requirements.

For capacity planning, this answer explicitly assumes a mature fictional platform with 800 million DAU, 1.5 billion MAU, 300 video starts per DAU per day, 40 feed requests per DAU per day, and a 5x event peak. Every uncited number in this answer is a stated design assumption, target, or budget — never a claim about any company's private architecture.

The four architectural planes

1. Signal plane: device batching, event ingestion, deduplication, sessionization, label joins, and the append-only telemetry backbone.
2. ML plane: feature store, offline and online training, model registry, evaluation gates, and staged rollout.
3. Serving plane: context assembly, multi-channel retrieval, cascaded ranking, re-ranking, prefetch, and delivery.
4. Content and governance plane: upload, transcoding, moderation verdicts, distribution state, policy, safety, and compliance.

A strong answer keeps these planes separate. The serving plane must keep working when training stalls. The signal plane must never block the serving plane. The governance plane must be able to remove any video from every channel without a model release.