Design TikTok

A full-screen feed of short videos for 1 B daily users, where the next clip starts instantly and every swipe reshapes what comes next.

Last updated 2026-10-26. Difficulty: hard. Patterns: short-video, prefetch, session-ranking, exploration, cdn. Reported at TikTok, Meta, Google, Snap, Pinterest, Amazon.

Functional requirements

• Post a short video. 15 s to 3 min, from a phone, with a caption, a sound and hashtags. Watchable within a minute of the upload finishing, at full quality a few minutes later.
• An endless, full-screen For You feed. One video at a time; a swipe starts the next one instantly, with no spinner, on Wi-Fi or on a weak cellular link.
• The feed adapts within the session. Completions, rewatches, quick skips, likes and shares change the next page of the feed, not tomorrow’s.
• Followed accounts mixed in. New uploads from accounts you follow appear in For You, at most one per page, as well as in a separate Following tab.
• No repeats. A video already watched does not come back for about four weeks, and never within the same session.
• Likes, comments, shares and follows. Each like counts exactly once per user. Like and comment counts show on every video.
• View counts. Shown rounded and approximate, refreshed within seconds; exact numbers for creator analytics come later from batch.
• A fair start for new videos and new users. A video from an account with no followers can reach a large audience if its viewers respond to it. A new user’s feed is personal within minutes.
• Safety before reach. Automated checks before the first view, human review before a video reaches a wide audience, and a removal stops distribution within minutes.
• Out of scope. Live streaming (see Design Twitch), direct messages, search, ads, creation tools and effects, music licensing and creator payouts. Long-video transcoding and ABR (Design YouTube) and ranking models (Recommendation System) only where short video changes them.

Non-functional requirements

• Scale (1 B DAU · 2 M starts/s peak). 50 B video starts and 30 M uploads a day. Every start is megabytes, so bandwidth, not request handling, is the bill.
• Swipe to first frame (p95 < 150 ms · < 1 % of swipes stall). This drives the hardest trade-off in the design: prefetching deeper makes more starts instant, but wastes more bytes on metered data and makes the feed slower to react to what the user just did.
• Data per start (~2.5 MB · prefetch waste < 10 %). Users on metered plans notice an app that eats data. Every byte fetched and never played is also egress paid for.
• Upload to watchable (p95 < 60 s after upload). Creators post and then watch the counter. One rendition and the automated checks are enough to go public; the full ladder follows.
• In-session freshness (every play shapes the next page). The feed is only as fast as its slowest loop that the user can feel. Outcomes ride on the page request, so the next page never waits for a stream.
• Feed page latency (p99 < 200 ms server side). Only the first page of a session is on the critical path; later pages are requested four videos early.
• Safety (checked before view 1 · reviewed before 20 k). A harmful video seen by 200 people is a takedown; seen by millions it is an incident. Reach grows in steps so that review comes before the big ones.
• Availability (99.95 % of opens play within 2 s). Degrade instead of failing: a cached, slightly stale feed or a popular one beats an error on the app’s only screen.

Back-of-envelope estimates

• Video starts per second: ~580 k/s avg · 2 M/s peak. 1 B DAU × 50 swipes = 50 B starts a day ÷ 86 400 ≈ 580 k/s. The evening peak is 2 M/s, about 3.5× the average. Each start is a view, a watch event and, usually, a few range requests for the rest of the clip.
• Feed pages per second: ~72 k/s avg · 250 k/s peak. Pages hold 8 videos: 2 M starts/s ÷ 8 = 250 k pages/s at peak; 50 B ÷ 8 = 6.25 B pages a day, ~72 k/s on average. Every page is filtered and ranked, so small pages cost more server work per video than a 50-video page would. That is the price of a feed that reacts.
• Bytes per start and peak egress: ~2.5 MB · ~40 Tbit/s. Average delivered bitrate ~1 Mbit/s (125 KB/s). A start fetches ~20 s of video: ~15 s watched plus ~5 s prefetched or buffered and never played. 20 × 125 KB = 2.5 MB. At peak 2 M/s × 2.5 MB = 5 TB/s ≈ 40 Tbit/s, ~125 PB a day. This is the single biggest cost in the system.
• Prefetch per swipe: ~250 KB · waste ~6 %. Each swipe moves the prefetch window by one, so one new head enters it: the first 2 s at ~1 Mbit/s ≈ 250 KB (200 KB at 540p on cellular, 375 KB at 720p on Wi-Fi). The waste is the heads still queued when the app closes: 4 × 250 KB ≈ 1 MB per session × 8 sessions × 1 B users ≈ 8 PB a day, ~6 % of egress.
• Uploads and the fast lane: ~350/s avg · ~1 k/s peak. 30 M ÷ 86 400 ≈ 350 uploads/s, ~1 k/s at peak. At ~15 MB per 30-s clip (encoded on the phone at ~4 Mbit/s) that is ~450 TB a day of originals. The fast 540p encode is ~5 core-seconds a clip, so even the peak needs only ~5 k cores; the rest of the ladder (~30 core-seconds) runs later on ~10 k.
• Rendition storage per day: ~300 TB/day. A 30-s clip at 360p (0.4 Mbit/s), 540p (0.8) and 720p (1.5) is 1.5 + 3 + 5.6 ≈ 10 MB. 30 M × 10 MB = 300 TB/day, ~110 PB a year. 1080p and HEVC copies are made only for the ~10 % of videos that pass the pool’s first stage, adding ~20 %. Originals go straight to an archive tier.
• Seen-set memory: ~2 TB · ~6 TB replicated. 50 plays a day × 28 days = 1 400 videos per user. A Bloom filter at 1 % false positives needs ~10 bits per entry: ~1.75 KB per user. 1 B users × 1.75 KB ≈ 1.75 TB, ~6 TB with three replicas: small enough to keep in memory beside the session state.
• Traffic-pool impressions: ~13 B/day · ~1 in 4 starts. 25 M eligible uploads × 200 test views = 5 B. The top 10 % get 2 000 (5 B), the top 5 % of those 20 000 (2.5 B), the top 2 % of those 200 000 (0.5 B): ~13 B of 50 B starts, about 2 slots in every page of 8. Only the first stage is a real cost; later stages show videos that have already proven themselves.

Components

• Edge PoPs (CDN + upload ingest): Hundreds of PoPs close to users, with regional shields behind them. They serve video bytes (heads of popular videos kept at the edge, bodies by range from the shield on a miss) and terminate uploads near the creator, relaying chunks to the regional store over the provider’s backbone. A short round trip is what makes both a 250 KB head and a 15 MB upload fast on a lossy cellular link.
• Video store (object storage · head + body): Originals (archive tier once encoded) and, per rendition, two immutable objects under a versioned path: a head (init segment plus the first 2 s, ~250 KB) and a body (the rest, in 2-s fragments read by byte range). Splitting the head out lets the CDN keep the most-requested bytes of every popular video at the edge while bodies sit at the shields. It is the CDN’s origin.
• Media pipeline (fast lane · ladder · auto checks): Triggered when an original lands. The fast lane decodes once, encodes a 540p rendition in about 2 s on 4 cores and, beside it, runs the automated checks: perceptual hashes against known illegal content, classifiers on a frame a second, speech and caption text, and an audio fingerprint. The slow lane adds 360p and 720p within minutes, and 1080p and HEVC only once the pool promotes a video.
• Video service (sharded SQL · by video id): Source of truth for each video: creator, caption, sound, status (public, restricted, removed), renditions with their real bitrates, plus a per-creator index of recent uploads for the following source. It makes a video public only once the fast lane and the automated checks have both reported, then admits it to the traffic pool. Feed hosts cache its serving records for at most 30 s, so a removal stops new serves within half a minute.
• Mobile app (player · queue · heads): Plays one full-screen video and keeps a queue of the next ones, with the first 2 s (the head) of the next 3 to 5 already downloaded and the next player decoding its first frame, so a swipe shows a picture at once. Asks for the next page of 8 when 4 unplayed videos remain, sending how each recent play went. Uploads in resumable chunks to the nearest edge, starting while the creator is still writing the caption.
• Feed service (per page · ~100 ms): Builds every page of 8, behind the usual API gateway (not drawn). Reads the session, seen filters and features in one round trip, folds in the outcomes the app sent, refreshes candidates when the session has moved, drops anything seen or not public, has ~200 scored, and fills slots for the pool and followed accounts. Then it picks one rendition per video for the app’s network class and signs the URLs. Stateless: the session lives in the online store.
• Model serving (ANN retrieval · GPU ranker): The slow-moving half of recommendation: an ANN index of recommendable videos queried with long-term and session vectors, and a multi-task ranker on GPUs with completion, rewatch, skip, like, share and follow heads. At 250 k pages/s × 200 candidates it scores 50 M rows a second, ~500 GPUs at peak. Retrained and rebuilt daily; within a session only its inputs change, never its weights.
• Moderation (human review queue): Human review for the pool’s winners before they reach 20,000 viewers, about 125 k videos a day ordered by how fast each is climbing, plus user reports and appeals. Verdicts go to the video service: approve, restrict (followers only, never recommended) or remove. The automated checks ran earlier, in the pipeline; this is where people look at what is about to be seen widely.
• Event stream (Kafka · key=user_id): One play event per video started (watch ms, length, loops, skipped within 2 s, rendition, stalls), plus likes and shares, batched by the app: ~2 M events a second at peak in ~500 k requests. Keyed by user so per-user state is updated in order; per-video aggregates are re-keyed and pre-aggregated downstream, so a viral video is never one hot partition.
• Engagement service (likes · follows · comments): Likes, comments, shares and follows, each a row written once per user, keyed by (video, user) or (follower, followee), with like and comment counts kept as sharded counters beside the rows. Serves a user’s followees to the feed at session start, and like counts and “liked by me” for the 8 videos of each page. A like is exact and idempotent; the count shown is rounded and may lag a second.
• Online store (KV · session · seen · stats): In-memory KV with three key families: per-session state (session vector, ids served this session, ~1,500 cached candidates, recent outcomes), per-user seen filters (four weekly Bloom filters, ~1.75 KB) and features, and per-video stats including the approximate view count. A user’s keys share a hash tag, so the user half of a page is one round trip. Losing a session costs a slightly less personal next page, never an error.
• Traffic pool (stages 200 → 200 k): Every new public video starts here with a test audience of 200, drawn from users whose interests sit near its content and, first, in its own region and language. When a stage’s views are in, it compares completion, rewatch, share and skip rates with videos of the same length and topic and promotes the top share to an audience ten times larger: 2,000, 20,000, then 200,000. Nothing passes 2,000 views without human review.
• Training (daily · offline): The slow loop. Joins a day of plays with the features the feed served, retrains the ranker and the two-tower embeddings, rebuilds the ANN index with yesterday’s pool graduates in it, and ships new versions to model serving after offline checks and a canary. Minute-fresh signals never wait for it: they reach the feed through the session and the stream.
• Stream processor (Flink · seconds): Turns plays into state within seconds: adds played videos to the user’s current seen filter, updates recent history and topic affinities, aggregates per-video stats (views, completion, rewatch, quick skips) every 5 s into the online store, and feeds each pool video’s stage counters. It also lands every event in the warehouse that training reads.

User flows

1. Swipe: the next video starts instantly. The main read path. Pages of 8 arrive a few videos before they are needed, and the first seconds of the next videos are already on the phone, so a swipe never waits for the network.
   1. The app asks for the next page when 4 unplayed videos remain, with its network class and how each recent play went. Asking four videos early hides the page’s latency completely: even a fast swiper at 2 s a video gives the server 8 s. The cursor names the page being asked for, so a retried request gets the same page back instead of advancing the session twice. The network class (20th-percentile throughput of the app’s recent downloads, metered or not, data saver) decides renditions and prefetch depth.
   2. The feed service reads the session, the seen filters and the user’s features in one round trip. All of a user’s keys share a hash tag, so they sit on one shard and come back in ~5 ms. The session holds the exact list of ids served in it, ~1,500 cached candidates, the session vector and recent outcomes. Four weekly Bloom filters cover the last 28 days of plays.
   3. If the session has moved, it refreshes candidates, and it asks the pool for new videos meant for this user. The session vector shifts with every play: toward clips completed or rewatched, away from quick skips. When it has moved past a threshold, or every 3 pages, a session ANN query brings ~300 fresh candidates; long-term ones stay cached for the session. The pool returns test and boosted videos whose target audience includes this user.
   4. Candidates already seen, already served this session or no longer public are dropped. Each of ~1,500 candidates is checked against the session’s served list and the four filters, all in memory, in well under a millisecond. Status and renditions come from serving records cached on the feed host for at most 30 s. A Bloom false positive hides an unseen video 1 % of the time, which nobody notices; a false negative would be a repeat, and Bloom filters never give one.
   5. The survivors are scored with the session’s fresh features, and the page of 8 is assembled. An in-process pre-ranker cuts ~1,500 to 200 and the GPU ranker scores those in ~40 ms. The page gets one test slot and up to one boosted slot from the pool, up to one new upload from a followed account (followees come from the engagement service once per session), and the rest by score, never two in a row by the same creator or with the same sound. Like counts for the 8 come back in the same batch call.
   6. For each video it picks one rendition for the network class and signs the URLs. Each class has a cap (data saver 360p, metered 540p, unmetered 720p or 1080p on a large screen), and within it the highest rendition this video has whose bitrate is at most two-thirds of measured throughput. One lower rendition comes along as an emergency fallback. A video minutes old may have only 540p, and is served at 540p everywhere rather than held back.
   7. The app prefetches the heads of the next videos, as deep as its network class allows. Depth 4 on Wi-Fi, 3 on cellular, 2 on a slow link, 1 with data saver. Heads are fetched in queue order and only while the playing video has 4 s buffered, so prefetch never starves what is on screen, and the next player decodes its first frame in the background. On cellular the window holds ~600 KB.
   8. On a swipe the first frame is already decoded, and the app fetches the body a few seconds ahead. Swipe to first frame is the swipe animation plus one frame, under 100 ms. The body comes in ~4-s ranges while the playhead is within a few seconds of the end of the buffer, never the whole file at once: a third of plays end within 3 s, and every byte past the playhead is thrown away on a swipe.
   9. An edge miss on a less popular video is filled from the regional shield, then the store. Heads of videos being served in a region stay at its edges; long-tail bodies come from the shield, which coalesces concurrent misses so the store sees about one request per object per region. A shield miss costs ~100 ms, which would hurt only for a head, and heads are fetched seconds before they are needed.
2. Post a video, watchable within a minute. The core write. The upload starts before the creator taps Post, one quick rendition and the automated checks run side by side, and the video is public before the full ladder exists.
   1. While the creator writes the caption, the app uploads the clip in chunks to the nearest edge. The phone has already encoded the clip (~4 Mbit/s 1080p, ~15 MB for 30 s) and starts uploading the moment editing ends, so for most posts the bytes are there before the caption is. Each 1 MB chunk is retried on its own. A PoP 10 ms away recovers from packet loss ten times faster than a region 100 ms away, which is what keeps a lossy uplink busy.
   2. On Post, the edge writes the original and the post’s details to the regional store, then acknowledges. The caption, sound, hashtags and visibility are written as a small manifest beside the original, so the post is durable the moment the app hears back, even if a core service is slow. The original is replicated across zones first, because it may be the creator’s only copy.
   3. The pipeline’s fast lane encodes one 540p rendition while the automated checks run beside it. The 540p encode with a fast preset is ~5 core-seconds for a 30-s clip, about 2 s on 4 cores. From the same decoded frames: perceptual hashes against known illegal content, classifiers on a frame a second, speech and caption text, and an audio fingerprint for music. A short clip is one job per rendition; splitting into chunks only pays near the 3-minute end.
   4. When both have reported, the pipeline writes the video record with its first rendition and the checks’ result. Pass: public, with renditions [540p]. Likely violation: restricted to the creator and queued for review. A match on known illegal content: removed and reported, never served. This happens ~20 to 30 s after the upload completed, and the checks, not the encode, are the long pole.
   5. The video service admits the new public video to the traffic pool at stage 0. The pool gets the video’s content embedding (frames, audio, caption) to find a test audience, its region and language, and its length bucket to compare it fairly. Followers can get it too, through the creator’s recent-uploads index. The video is now watchable, inside the minute.
   6. Within minutes the slow lane adds 360p and 720p, and the video service lists them. Until then everyone gets 540p, which beats waiting. The slow lane uses slower presets for better quality per bit at low priority, so a surge of uploads delays full quality, not publishing. 1080p and HEVC are encoded only when the pool promotes the video past stage 0; ~90 % of uploads never need them.
3. A new video climbs the pool and goes viral. Cold start and the scale-breaking case. A video from an account with no followers earns each larger audience with its own numbers, passes human review before 20,000 people see it, then has to survive 50,000 starts a second.
   1. Feeds of users close to the video’s content give it their test slot until it has 200 views. The test audience is chosen by content embedding and region first: viewers whose vectors are near it, in its language, so the 200 views land on people likely to care, and behind a few PoPs. A page carries at most one test video, and the pool hands each one out against its remaining quota.
   2. Each play’s outcome reaches the video’s stage counters within seconds. Views, completions, rewatches, skips within 2 s, likes, shares and follows, counted per stage and once per viewer. At 200 views a completion rate is known to about ±3 points: enough to separate the top tenth from the middle, not enough to rank within the top tenth.
   3. With its views in, the pool compares it with videos of the same length and topic and promotes the top 10 %. The score combines completion, rewatch, share and follow rates minus quick skips, each normalised against its cohort, because a 15-s clip completes far more often than a 3-minute one. It uses the lower end of a confidence interval, so 3 shares from 20 views does not beat 30 from 200. Promoted videos get 2,000 more views; the rest stay recommendable at a trickle, and a late surge can re-open promotion.
   4. Promoted again past 2,000 views, it waits for human review before going to 20,000. About 125 k videos a day reach this gate. The queue is ordered by how fast each is climbing, so a video gaining views quickly gets a person in minutes. While it waits it keeps its stage-1 audience: nothing is lost but time.
   5. The reviewer approves it; the video service tells the pool, which opens stage 2. Stage 2 is 20,000 views and stage 3 is 200,000, after which the video leaves the pool and competes on its own scores. The pool knows which regions its next views go to before they happen, so it warms the video’s heads at those edges. The pipeline now adds 1080p and HEVC, because this video’s egress will pay for them.
   6. It graduates and takes off: 50,000 starts a second, served from edge memory. At 50 k starts a second this one video is 2.5 % of all traffic: ~150 k edge requests a second (a head and a couple of body ranges per start) and ~1 Tbit/s. Its heads at two or three renditions are a few hundred KB each, held in memory at every edge in the regions serving it, and each shield fetched each object once.
   7. Views are aggregated per 5 s before they are written; likes are rows with sharded counts. The stream processor counts views per video per 5 s and writes one increment per window to each of 16 sub-keys once a video is hot: 50 k views a second become ~3 writes a second. A like is a row keyed by (video, user), so it counts once; its counter is sharded and summed on read with a 1-s cache. Both are shown rounded (“1.2M”), so seconds of lag are invisible.
4. Weak signal, retries and a degraded feed. The failure path. The queue on the phone is the buffer: a clip steps down one rendition rather than stalling, prefetch stops before playback suffers, a failed page request is retried without advancing the session twice, and a struggling feed serves a stale page rather than none.
   1. Throughput falls from 4 Mbit/s to 700 kbit/s while a 540p clip plays. The app sees it within one range request. Prefetching further heads stops at once, because the video on screen has priority over everything queued behind it.
   2. With under 1 s buffered, the app switches the rest of this clip to the fallback rendition. The fallback URL came with the page. Fragments are 2 s and keyframe-aligned across renditions, so the switch happens at the next fragment without a glitch. This is the only mid-clip switch the player makes: an emergency step down, never a step up.
   3. The user keeps swiping; the heads already queued still start instantly. Three heads are on the phone, so the next three swipes still play from memory, and their bodies are fetched at the fallback rendition. The app also lowers its measured throughput for the next page request.
   4. The next-page request times out, and the app retries with the same cursor. Retries back off from 1 s. Because the server keys the request by (session, cursor), a retry after the page was already built returns that same page: the session does not record 8 videos as served that never arrived, and the outcomes are not folded in twice.
   5. The feed service picks 360p for every video on the slow link. At ~700 kbit/s two-thirds is ~470 kbit/s, so 360p (~390 kbit/s) for each video, with heads of ~100 KB and a prefetch depth of 2. A slow link gets fewer, smaller heads instead of stalls.
   6. If ranking is overloaded, the feed service serves the session’s cached candidates in their last order. The session already holds ~1,500 ranked candidates from its last refresh. Filtered again for seen and status, their stored order is a page a few minutes stale but still personal. With no session at all it falls back to popular in region and language, the path every signed-out user takes, so it is always warm.
   7. The signal returns; the next page arrives and the app rebuilds its prefetch window. The first downloads re-measure throughput, and the class goes back up on the following page. Videos already queued at 360p stay at 360p: upgrading them would throw away heads that are already on the phone.
5. Skips and rewatches reshape the next page. The feedback loop at three speeds. Outcomes ride on the next page request and change it at once; the stream turns them into seen filters and stats within seconds; the models learn from them overnight.
   1. The user skips three cooking videos within a second each, then watches a cycling clip twice. Every play ends with an outcome: watched 0.8 s of 24 s, skipped; watched 62 s of a 31-s clip, one loop. On a short-video feed these arrive every few seconds, which is why a session can learn so fast: 20 labelled plays in five minutes, where a long-video home page gets one or two.
   2. The app sends each outcome to the event stream in small batches. Every 4 plays or 20 s, and when the app goes to the background, with client event ids so a retried batch is harmless: ~2 M events a second at peak in ~500 k requests. The same outcomes also ride on the next page request, so the session never waits for the stream.
   3. The next page request carries the same outcomes, and the feed service folds them into the session. The session vector moves toward the clip watched twice and away from the three skipped, weighted by watch fraction: 0.8 s of 24 s is a clear negative, a loop a strong positive. Per-topic, per-creator and per-sound counters record “cooking: 3 skips”. This is state, not learning: no model changes.
   4. The session has moved, so candidates are refreshed and the ranker scores them with the new session features. A session ANN query with the new vector brings ~300 candidates near cycling. The session counters and last 20 outcomes are ranker inputs, so cooking videos still in the cached list now score lower. The page has more cycling, a cooking video at most, and its usual test slot: exploration continues, or the session would collapse onto one topic.
   5. Within seconds the stream processor adds the plays to the seen filter and updates the videos’ stats. Played videos go into this week’s Bloom filter; four weeks later that slice is dropped, which is how a Bloom filter gets a TTL. Per-video completion and skip rates are aggregated per 5 s for the ranker’s features. Until a play reaches the filter, the session’s exact served list keeps it out.
   6. Overnight, training joins the day’s plays with the features served, and ships new models. The ranker learns patterns across users, say that loops on cycling clips predict follows, and the embeddings place yesterday’s pool graduates near what their viewers also liked. New versions ship after offline checks and a 1 % canary. Daily is enough because the session carries the last minutes and the stream the last hour.

Deep dives

The theory behind it

• Video streaming: transcoding, HLS, DASH and adaptive bitrate: How online video works end to end: uploads, transcoding into a bitrate ladder, segmenting for HLS and DASH, adaptive bitrate in the player, CDN delivery, live versus on-demand, and the numbers behind it.
• Recommendation systems: How large recommendation systems are built: candidate generation, ranking and re-ranking, embeddings and two-tower models, features and feature stores, offline and online serving, feedback loops, cold start, and how to evaluate them.
• Multi-armed bandits and exploration: Learning what works while serving users: the explore-exploit trade-off, epsilon-greedy, upper confidence bounds and Thompson sampling, contextual bandits, bandits versus A/B tests, uses in ranking, notifications, pricing and creative selection, logging for off-policy evaluation, and pitfalls.

Related

• Design a URL Shortener
• Design YouTube
• Design Google Maps
• Design a Project-to-Contractor Matching System
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit