System Design Interview
Short-video platform inspired by TikTok: async transcoding into adaptive-bitrate renditions, CDN playback with prefetch, a two-stage For You recommender (retrieval, then ranking) and near-real-time learning from engagement, as described in ByteDance's Monolith paper (2022). A teaching design, not ByteDance's internal architecture.
See why storing and streaming video through one server and database can't work.
What was missing: Nothing yet: one server receives, stores and streams every clip.
Why that's risky: Every view streams megabytes out of the database through one server, there's one quality for every network, and the feed is just the newest clips.
What gets added: An app server and a database holding each video file in its row.
Trade-offs: Trivial to build, but video is far too heavy for a database and an application server.
Accept uploads quickly and encode them in the background into renditions for every network speed.
What was missing: Videos lived in database rows in one format, encoded during the upload request.
Why that's risky: Viewers still pull every segment from storage through the playback service, which melts under viral clips.
What gets added: An upload service that creates the record and issues a signed URL so the original goes straight to object storage, a transcode queue, and transcoders that build an adaptive-bitrate ladder of HLS segments. A playback service returns manifests.
Trade-offs: A new clip takes a short while to become playable while it's encoded, in exchange for an upload that returns in under a second.
Serve segments from servers near viewers and make swiping instant.
What was missing: Every segment came from origin storage through application servers.
Why that's risky: The feed is still just recent clips: nothing learns what each viewer likes.
What gets added: A video CDN in front of rendition storage, a metadata cache for hot records and manifests, and client prefetch of the next clips' first segments.
Trade-offs: Segments are immutable, so they can be cached for a long time; removing a clip means invalidating its manifest, not its segments.
Pick the next clips for each viewer from billions in well under a second.
What was missing: No personalization: the same recent clips for everyone.
Why that's risky: The model learns only from old data: likes and viewing time aren't captured or fed back yet.
What gets added: A feed service that runs two stages: candidate retrieval (nearest neighbours of the viewer's interest embedding, followed accounts, trending pools) narrows billions to thousands, then a ranking model scores those on fresh features and keeps a few dozen. An online feature store and its durable copy hold the features.
Trade-offs: Retrieval is cheap and approximate, ranking is expensive and precise; splitting them keeps latency bounded.
Capture every like and how long each clip was viewed, and feed it back into recommendations within minutes.
What was missing: User actions weren't recorded or used, so recommendations couldn't adapt.
Why that's risky: New posts go live without policy or copyright checks, and the feed has no ads.
What gets added: An engagement service that stores likes, comments and follows and publishes every action to an event stream; an online trainer that updates the model and embeddings within minutes; and an aggregator for counts, creator analytics and trends.
Trade-offs: Counts are eventually consistent (a like may take a moment to show); the model updates continuously instead of in daily batches.
Check every post before it goes live, monetize the feed, and watch quality of experience.
What was missing: Posts went live unchecked, nothing paid for the feed, and nobody could see start-up time or rebuffering.
Why that's risky: Remaining risk is regional: losing a region needs failover of the feed, metadata and CDN routing.
What gets added: A moderation queue and workers (policy classifiers, audio fingerprinting for copyright) that gate a clip going live; an ads service filling sponsored feed slots; and monitoring of start-up time, rebuffering, feed latency and backlogs.
Trade-offs: Moderation delays a clip going live by seconds to minutes; borderline cases wait for human review.
Use ABR with HLS/DASH, small segments, quick-start low-bitrate renditions, aggressive CDN edge caching, and client prefetch of the next likely video.
Run layered moderation: reputation checks at upload time, async policy classifiers, copyright/audio fingerprint matching, and human review/takedown workflows.
Use CDN origin shielding, autoscale feed and metadata services, coalesce hot requests, and prioritize prefetch/caching of manifests and hot segments for the viral object.
Combine trending content, regional priors, demographic-safe bootstrapping, creator diversity, and simple onboarding signals until enough watch/skip/dwell data exists for personalization.
Retrieval finds a broad candidate pool quickly using embeddings, trending pools, and heuristics. Ranking then applies more expensive scoring on a smaller set using online features, quality signals, and safety rules. Separating them keeps latency tractable.
Stream engagement events asynchronously, aggregate them nearline/offline, and serve creators from a dedicated analytics store rather than reading directly from operational counters or the watch path.
Insert sponsored candidates in a separate ad-serving step with pacing, auction, and policy constraints. Apply strict latency budgets, relevance thresholds, and frequency caps; fall back gracefully if ad systems are unavailable.
Keep playback and manifest delivery independent from ranking and moderation pipelines. Recommendation can degrade to cached or trending pools, and moderation decisions can apply asynchronously with emergency blocks for high-risk content.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
