Design TikTok

Design TikTok

Designing TikTok involves building a short-form video platform capable of serving billions of users with personalized content, real-time engagement, and viral content distribution. The system must handle massive video uploads, process them efficiently, generate highly personalized “For You” feeds using machine learning, and support interactive features like duets, stitches, and trending sounds.

The core challenge lies in balancing three critical dimensions: processing 500 million video uploads daily with minimal latency, generating personalized feeds for over a billion users in under 500 milliseconds, and handling viral content spikes that can generate millions of views within minutes.

Step 1: Understand the Problem and Establish Design Scope

Before diving into the architecture, it’s crucial to define the functional and non-functional requirements. For a platform like TikTok, functional requirements define what users and creators can do, while non-functional requirements establish the system qualities around scale, performance, and reliability.

Functional Requirements

Core Requirements (Priority 1-3):

1. Users should be able to upload short-form videos ranging from 15 seconds to 10 minutes in length.
2. Users should be able to view a personalized “For You” feed that displays videos matched to their interests.
3. Users should be able to engage with videos through likes, comments, shares, and saves.
4. Users should be able to follow creators and view videos from accounts they follow.

Below the Line (Out of Scope):

• Users should be able to create duets by recording side-by-side with existing videos.
• Users should be able to create stitches by adding content to clips from other videos.
• Users should be able to search for content via hashtags, sounds, and user profiles.
• Creators should be able to view detailed analytics about their video performance.
• Users should be able to participate in live streaming and direct messaging.

Non-Functional Requirements

Core Requirements:

• The system should provide feed load times under 500 milliseconds to maintain user engagement.
• The system should start video playback within 200 milliseconds to create a seamless viewing experience.
• The system should process uploaded videos within 2 minutes to enable quick content distribution.
• The system should maintain 99.99% uptime to ensure constant availability for global users.
• The system should handle eventual consistency for engagement metrics while maintaining strong consistency for user authentication.

Below the Line (Out of Scope):

• The system should implement comprehensive content moderation to detect inappropriate material.
• The system should comply with data privacy regulations like GDPR and COPPA.
• The system should provide disaster recovery with less than 1 hour RTO.
• The system should support zero-downtime deployments.

Clarification Questions & Assumptions:

• Platform: Mobile apps for iOS and Android, plus web interface.
• Scale: 1 billion monthly active users with 100 million daily active users. 2 million active drivers sending location updates.
• Video Volume: 500 million videos uploaded daily, generating 10 billion video views per day.
• Storage Growth: Approximately 30 petabytes of new video storage daily across multiple resolutions.
• Geographic Coverage: Global with multi-region deployment focused on major markets.
• Content Delivery: Heavy reliance on CDN infrastructure for video distribution.

Step 2: Propose High-Level Design and Get Buy-in

Planning the Approach

For a video platform like TikTok, the design strategy should start with the basic video upload and playback capabilities, then layer in the personalized feed algorithm, engagement features, and viral content handling. This sequential approach ensures we build a solid foundation before adding complexity.

Defining the Core Entities

To satisfy our key functional requirements, we’ll need the following entities:

User: Any person using the platform, whether as a creator or viewer. Contains personal information, preferences, authentication credentials, and a record of their interactions with content. Each user has a unique embedding vector that represents their content preferences for the recommendation algorithm.

Video: The primary content unit representing an uploaded video. Includes the video files at multiple resolutions, metadata like duration and resolution, processing status, upload timestamp, caption text, hashtags, and references to the audio track used. Videos also maintain aggregated engagement metrics like view counts, likes, comments, and shares.

Creator: Users who produce content on the platform. Contains additional information beyond regular users, including follower counts, total video views, engagement rates, analytics access, and monetization status. Creators have profiles that showcase their content and allow others to follow them.

Engagement: Records of user interactions with videos. Includes likes, comments, shares, saves, and watch time data. These interactions feed into both the recommendation algorithm and analytics systems. Comments form threaded conversations with causal consistency.

Sound: Audio tracks that can be used in videos. Contains the audio file, metadata about the song or sound, licensing information, usage count, and trending status. Sounds can be original creations or licensed music from the platform’s library.

Feed: A personalized collection of videos generated for each user. Represents the ranked list of videos shown in the “For You” page, calculated using machine learning models that consider user preferences, video quality, engagement signals, and diversity constraints.

API Design

Video Upload Initialization: Used by creators to request a pre-signed URL for uploading video content directly to object storage.

POST /videos/upload-url -> UploadURL
Body: {
  duration: number,
  fileSize: number,
  mimeType: string
}

Video Metadata Submission: Used after video upload completes to submit caption, hashtags, sound selection, and other metadata.

POST /videos -> Video
Body: {
  videoId: string,
  caption: string,
  hashtags: string[],
  soundId: string
}

Get Personalized Feed: Used to retrieve the personalized “For You” feed for the current user.

GET /feed/for-you?cursor={token}&count=20 -> FeedResponse

Returns a list of videos with metadata, creator information, engagement counts, and a cursor token for pagination.

Engage with Video: Used to record user engagement actions like likes, comments, shares.

POST /videos/:videoId/engagement -> Success
Body: {
  action: "like" | "unlike" | "comment" | "share" | "save",
  commentText?: string
}

Follow Creator: Allows users to follow content creators.

POST /users/:userId/follow -> Success
Body: {
  action: "follow" | "unfollow"
}

High-Level Architecture

Let’s build up the system sequentially, addressing each functional requirement:

1. Users should be able to upload short-form videos

The core components for video upload are:

• Mobile/Web Client: The user interface where creators record or select videos, add captions and hashtags, and initiate uploads. Uses native video recording APIs on mobile devices.
• API Gateway: Entry point for all client requests, handling authentication via JWT tokens, rate limiting to prevent abuse, and routing to appropriate backend services.
• Video Service: Manages the video upload lifecycle. Generates pre-signed URLs for direct uploads to object storage, validates video format and size, creates video metadata records, and triggers the processing pipeline.
• Object Storage: Scalable blob storage for raw and processed video files. Uses services like Amazon S3 with appropriate bucket organization and lifecycle policies.
• Message Queue: Durable messaging system like Apache Kafka that receives video processing events and ensures no uploads are lost even during system failures.
• Video Processing Pipeline: Distributed workers that transcode videos to multiple resolutions, generate thumbnails, perform content moderation, extract audio, and enrich metadata with computer vision analysis.

Video Upload Flow:

1. The creator records or selects a video in the client app and adds caption, hashtags, and sound selection.
2. The client requests a pre-signed upload URL from the Video Service via the API Gateway.
3. The Video Service validates the request, generates a unique video ID using a distributed ID generator, creates a pre-signed S3 URL with appropriate permissions, and returns it to the client.
4. The client uploads the video file directly to S3 using the pre-signed URL, utilizing multipart upload for reliability and resumability.
5. Upon successful upload, S3 triggers an event notification that reaches the Video Service.
6. The Video Service creates a video metadata record in the database with status “processing” and publishes a processing event to the Kafka message queue.
7. Video processing workers consume events from Kafka and begin transcoding the video to multiple resolutions including 360p for low bandwidth, 480p for standard mobile, 720p for HD default, and 1080p for high quality.
8. Workers generate thumbnails at multiple points in the video, create animated preview clips, perform content moderation using computer vision to detect policy violations, and extract metadata like objects, scenes, and faces.
9. Processed video files are uploaded to S3 organized by video ID and resolution, and the CDN cache is invalidated to ensure fresh content delivery.
10. The Video Service updates the database with processing status “complete” and the creator receives a notification that their video is live.

2. Users should be able to view a personalized “For You” feed

We extend our design with sophisticated ranking and recommendation:

• Feed Service: Core service responsible for generating personalized video feeds. Orchestrates the multi-stage ranking pipeline and manages feed caching.
• ML Service: Machine learning infrastructure that maintains user embeddings, generates video recommendations, scores candidate videos, and continuously learns from user interactions.
• Feature Store: Specialized database storing pre-computed user and video embeddings used for real-time recommendation. Contains user interest vectors, video content embeddings, and interaction history.
• Vector Database: Optimized storage for high-dimensional embedding vectors with support for approximate nearest neighbor search. Uses systems like Pinecone or Milvus.
• Cache Layer: Distributed caching using Redis to store generated feeds, user session data, trending content, and frequently accessed video metadata.

For You Feed Generation Flow:

1. The user opens the app or pulls to refresh, sending a GET request to the feed endpoint.
2. The API Gateway authenticates the request and forwards it to the Feed Service.
3. The Feed Service first checks the Redis cache for a recently generated feed for this user.
4. On cache miss, the service initiates the candidate generation phase, retrieving approximately 10,000 potential videos from multiple sources.
5. Candidate sources include collaborative filtering to find videos liked by similar users, content-based filtering matching videos to user interests, videos from followed creators weighted by relationship strength, globally and regionally trending content, and exploration content for diversity.
6. The service queries the Vector Database using the user’s embedding vector to find similar video embeddings efficiently using approximate nearest neighbor algorithms.
7. The candidate videos are then sent to the ranking phase, where the ML Service uses a two-tower deep neural network to score each video based on predicted watch time.
8. The model considers over 200 features including user demographics and historical interactions, video engagement metrics and quality scores, context like time of day and device type, and interaction features measuring user-video similarity.
9. After ML ranking, a re-ranking phase applies business logic like ensuring diversity by limiting videos per creator, boosting fresh content under one hour old, prioritizing content from followed creators, removing flagged content, and inserting sponsored content at appropriate intervals.
10. The top 20-30 videos are selected, cached in Redis with a 5-minute TTL, and returned to the client along with prefetch URLs for smooth scrolling.
11. The client begins preloading the next three videos in the background while the user watches the current video.

3. Users should be able to engage with videos through likes, comments, shares, and saves

We add engagement tracking infrastructure:

• Engagement Service: Handles all user interaction events including likes, unlikes, comments, comment replies, shares, and saves. Validates actions, updates counters, and publishes events.
• Social Graph Database: Stores follower relationships using a graph-optimized database or wide-column store like Cassandra. Efficiently answers queries about who follows whom.
• Analytics Service: Processes engagement events to generate real-time metrics, creator dashboards, trending detection, and business intelligence reports.
• Real-time Processing: Uses Apache Flink for streaming analytics on engagement events, computing metrics over sliding time windows.

Engagement Flow:

1. The user performs an action like liking a video in the client app.
2. The client sends an engagement request to the API Gateway with the action type and video ID.
3. The API Gateway routes to the Engagement Service, which validates the action and checks for duplicates.
4. For like actions, the service increments the like counter in the database and creates an engagement record linking the user to the video.
5. The engagement event is published to Kafka for downstream processing.
6. The Analytics Service consumes the event and updates real-time metrics stored in Redis sorted sets for trending detection.
7. The ML Service updates the user’s interest profile based on the engagement, strengthening the connection between the user embedding and the video’s content features.
8. The client immediately reflects the engagement in the UI with optimistic updates, while the actual database write happens asynchronously.
9. For comment actions, the service stores the comment text with threading information to support nested replies and maintains causal consistency in the comment ordering.
10. The cache is selectively invalidated for affected entities like the video’s engagement counts and the user’s engagement history.

4. Users should be able to follow creators and view videos from accounts they follow

We enhance the social graph capabilities:

• User Service: Manages user profiles, authentication, follow relationships, and privacy settings. Handles operations like follow, unfollow, block, and profile updates.
• Following Feed Service: Generates chronological feeds of content from followed creators, separate from the algorithmic “For You” feed. Uses a fan-out approach for active creators.

Following Flow:

1. The user navigates to a creator’s profile and taps the follow button.
2. The client sends a follow request to the API Gateway.
3. The User Service validates the request and updates the social graph database, adding an edge from the follower to the followee.
4. The service updates both the follower’s following count and the creator’s follower count using atomic counter operations.
5. A follow event is published to Kafka for analytics and feed generation.
6. The Following Feed Service uses a fan-out on write approach for popular creators, where new videos are pushed to the feeds of all followers, or a fan-out on read approach for mega creators with millions of followers, where feeds are generated on demand.
7. For moderate-size creators, the system uses a hybrid approach, pre-computing partial feeds and completing them at read time.

Step 3: Design Deep Dive

With the core functional requirements met, it’s time to address the complex challenges that make TikTok a technically fascinating system. These deep dives tackle the non-functional requirements around performance, scale, and reliability.

Deep Dive 1: How do we efficiently process and store 500 million videos daily across multiple resolutions?

Processing half a billion videos daily with minimal latency while maintaining quality and controlling costs is a massive challenge. Naive approaches would either be prohibitively expensive or too slow to meet user expectations.

The Video Transcoding Challenge:

A typical 60-second video at 720p resolution is approximately 5 MB in size. With 500 million daily uploads, we’re looking at 2.5 petabytes per day of raw video. But we need to transcode each video into at least four resolutions, multiplying storage by 4x before considering replication. The processing pipeline must handle this volume while keeping latency under 2 minutes.

Solution: Distributed Priority-Based Processing Pipeline

The architecture uses a multi-stage pipeline with intelligent queuing and distributed workers:

We organize processing into priority tiers. High priority goes to verified creators with large followings since their content is more likely to go viral. Normal priority serves regular active users. Low priority handles new users whose content has uncertain engagement potential. This ensures quality content reaches audiences quickly while still processing all uploads.

When a video arrives in object storage, an event notification triggers the pipeline. The system generates a unique identifier using Snowflake ID generation for distributed uniqueness. Basic metadata extraction pulls duration, resolution, codec information, and file integrity checks run immediately to catch corrupted uploads.

The pre-processing stage performs content moderation using computer vision services like AWS Rekognition to detect policy violations including violence, explicit content, and copyrighted material. Videos that violate policies are automatically rejected with notifications sent to the creator. For videos that pass moderation, we extract faces for privacy features, analyze audio for copyrighted music using acoustic fingerprinting, and flag potential issues.

The transcoding stage leverages distributed worker fleets running on Kubernetes with auto-scaling based on queue depth. Each video is transcoded to multiple resolutions using FFmpeg or cloud services like AWS MediaConvert. We use H.264 codec for broad compatibility, H.265 for bandwidth savings on supported devices, and VP9 for web browsers. The output is packaged for adaptive bitrate streaming using HLS or DASH protocols with 2-second segments.

Optimization Techniques:

To achieve the required performance at acceptable cost, several optimizations are critical. Parallel segment processing splits videos into chunks, transcodes them simultaneously across multiple workers, then merges results. This reduces processing time by 70% for longer videos. GPU acceleration using NVIDIA hardware provides 5x faster encoding compared to CPU-only transcoding.

Lazy transcoding is employed for less popular content. Initially, only 720p is generated for immediate distribution. Other resolutions are created on-demand when requested, reducing unnecessary processing for videos that receive few views. Smart encoding uses machine learning to determine optimal bitrate based on content complexity, reducing file size by 30% without quality loss for simpler content.

Region-specific processing routes uploads to the geographically nearest processing cluster, reducing upload latency and enabling faster distribution. Time-of-day scheduling runs batch processing jobs during off-peak hours when compute is cheaper.

Storage Organization and Lifecycle:

Videos are organized in object storage with a structured hierarchy. Raw videos land in buckets organized by year, month, and day for efficient lifecycle management. Processed videos are stored by video ID with subdirectories for each resolution. Thumbnails, audio tracks, and metadata are separated into specialized buckets optimized for their access patterns.

Lifecycle policies automatically transition raw videos to cold storage after 30 days since they’re rarely needed once processing completes. Videos with low view counts after 90 days move to cheaper storage tiers using intelligent tiering that analyzes access patterns. Hot videos identified by view velocity are replicated across all geographic regions for faster access.

CDN integration with CloudFront or Akamai uses origin shield to reduce S3 egress costs by adding a caching layer between edge locations and origin, consolidating requests and reducing redundant fetches from S3.

Deep Dive 2: How do we generate personalized feeds for a billion users in under 500 milliseconds?

Creating relevant, engaging feeds at massive scale with strict latency requirements demands sophisticated machine learning infrastructure and careful system design. The naive approach of scoring every video for every user would require billions of inference operations and take far too long.

The Multi-Stage Ranking Pipeline:

The solution uses a funnel approach with three distinct stages, each optimized for different goals.

Stage 1: Candidate Generation (Recall)

The goal is to quickly retrieve around 10,000 candidate videos from a pool of billions, completing in under 100 milliseconds. Quality at this stage is less critical than coverage and speed.

We employ multiple retrieval strategies run in parallel. Collaborative filtering finds users with similar interaction patterns using approximate nearest neighbor search on user embedding vectors stored in the Feature Store. The system retrieves videos that similar users have engaged with, providing strong signals from community wisdom.

Content-based filtering matches video characteristics to user interests. Each video has an embedding vector computed by running ResNet on video frames and extracting features. These embeddings are stored in a vector database optimized for similarity search. The user’s historical preferences are also represented as an embedding vector. Cosine similarity between user and video embeddings identifies matches.

The social graph provides videos from creators the user follows, weighted by the strength of the relationship measured by past engagement. Recent videos from close follows receive higher weight than older videos from casual follows.

Trending content ensures users see what’s popular. Global, regional, and category-specific trending lists are pre-computed every few minutes by the Analytics Service. These provide serendipitous discovery and cultural relevance.

Exploration content injects randomness into the feed. About 10% of candidates are randomly selected from the entire corpus, enabling cold-start distribution for new creators and helping the system learn about changing user preferences.

Each source contributes candidates with specific weights: collaborative filtering provides 40%, content-based filtering 30%, social graph 20%, trending 5%, and exploration 5%. Deduplication removes videos the user has already seen or videos appearing from multiple sources.

Stage 2: Ranking (Precision)

With 10,000 candidates, we now invest more compute to predict which videos will truly engage the user. The goal is to produce a ranked top-100 list in under 200 milliseconds.

The ranking model is a two-tower deep neural network. One tower processes user features including demographics like age, gender, and location, historical interactions recording watch time, likes, shares, and comments, interest categories derived from past behavior, activity patterns capturing time-of-day and device preferences, and social features like follower and following counts.

The other tower processes video features including engagement metrics like view count, like rate, comment rate, and share rate, quality scores from content analysis, creator reputation based on follower count and past performance, freshness measuring video age with recency boost, category and hashtag information, and audio popularity if the video uses a trending sound.

Context features are injected into both towers: current time of day, day of week, device type, network quality, and current session behavior.

The towers each produce embedding vectors. The user tower outputs a 128-dimensional vector representing the user’s preferences in this context. The video tower outputs a 128-dimensional vector representing the video’s characteristics. The dot product of these vectors produces the relevance score.

The model is trained to predict watch time divided by video duration, effectively predicting completion rate. Positive training examples are videos watched for at least 80%, negative examples are videos skipped within 10%. The training dataset contains over 100 billion interactions refreshed continuously.

Optimization techniques make inference fast. Batch inference scores all 10,000 candidates in a single forward pass, leveraging GPU parallelism. User features are cached in Redis with a 5-minute TTL since they don’t change frequently. Model quantization using INT8 precision provides 4x speedup with minimal accuracy loss. The model is served using TensorFlow Serving on GPU-equipped machines.

The model is retrained every 6 hours using fresh interaction data, keeping it responsive to emerging trends. A/B testing framework continuously evaluates model variants on small traffic percentages before full rollout.

Stage 3: Re-ranking (Business Logic)

The ML model produces a raw ranking, but business considerations require adjustments. This stage applies rules and constraints while maintaining the core ranking quality.

Diversity constraints prevent feed monotony. No more than two consecutive videos from the same creator appear in the top 20. Category diversity ensures varied content types. The system avoids showing multiple videos with the same sound back-to-back.

Freshness boosting increases scores for videos less than one hour old by 20%, helping new content gain initial traction. Content from followed creators receives a 30% boost since explicit follows signal strong interest.

Content policy filters remove videos flagged for review or violating community guidelines. These removals happen in real-time as moderation decisions are made.

Sponsored content insertion places advertisements every 5th video, clearly marked and targeted based on user interests. Local content requirements ensure 30% of videos come from the user’s geographic region to maintain cultural relevance.

Exploration injection guarantees at least 10% of videos have lower ML scores, enabling the system to learn about changing preferences and serendipitously delight users with unexpected content.

Caching Strategy:

Generated feeds are cached in Redis using a compound key of user ID and a 5-minute time bucket. The TTL is set to 5 minutes, balancing freshness with cache hit rate. On cache hit, the feed is immediately returned with markers for previously viewed videos. On cache miss, the full pipeline executes and results are cached for future requests.

Deep Dive 3: How do we provide seamless infinite scroll with under 100 milliseconds between videos?

The signature TikTok experience is effortless scrolling through an endless feed of videos. Achieving this requires careful coordination between feed generation, video preloading, and smart buffering.

Progressive Prefetching:

The client implements an aggressive prefetching strategy. While the user watches the current video, the next three videos are downloaded in the background. This ensures that when the user swipes, the next video is already available locally.

Metadata for the next 10 videos is prefetched as well, allowing the UI to render preview information. Thumbnails for the next 20 videos are loaded, enabling smooth scroll through the feed preview if the user rapidly swipes.

Adaptive Quality Selection:

The client continuously monitors network conditions. On 5G or WiFi, it downloads 1080p or 720p videos. On 4G LTE, it defaults to 720p. On slower connections, it falls back to 480p or 360p. The quality can dynamically change mid-stream if network conditions deteriorate.

This adaptive bitrate streaming is implemented using HLS or DASH protocols. The video is segmented into 2-second chunks, each available at multiple quality levels. The player can switch quality between segments based on current buffer level and bandwidth.

Feed Pagination:

As the user scrolls through their feed, the client tracks their position and requests additional content before they reach the end. When the user reaches video 10, the client fetches the next batch of 20 videos. The request includes a cursor token that encodes the feed state.

The cursor is a JWT token containing user ID, timestamp of feed generation, last video ID seen, and a feed session ID. This allows the server to continue from the exact point where the previous request ended, maintaining consistency even as new videos are uploaded.

The API response includes not only the video list but also prefetch URLs with CDN optimization, allowing the client to begin downloading immediately.

Smart Buffering:

The video player buffers 5-10 seconds ahead of the current playback position. If the user pauses, buffering also pauses to conserve bandwidth. When the user resumes or shows intent to continue by touching the screen, buffering resumes.

For videos in the preload queue, the client downloads only the first 10 seconds initially, ensuring quick start time if the user swipes to that video. Full download completes in the background based on priority.

CDN and Edge Optimization:

Videos are distributed through a global CDN with hundreds of edge locations. The CDN uses origin shield to add a regional cache layer between edge locations and origin, reducing origin load. Segment-based caching at edge locations provides sub-100ms latency for popular content.

HTTP/2 server push is utilized where supported, with the server proactively pushing segments of the next video while the user watches the current one.

Deep Dive 4: How do we detect and scale for viral content in real-time?

Viral videos can explode from thousands of views to millions within an hour, creating sudden traffic spikes that can overwhelm infrastructure. The system must detect emerging viral content early and automatically scale resources to handle the load.

Real-Time Trending Detection:

The analytics pipeline uses Apache Flink for streaming computation. Engagement events like views, likes, comments, and shares flow through Kafka into Flink jobs. The system uses sliding time windows to aggregate metrics, typically one-hour windows updated every 5 minutes.

For each video, we calculate a trending score using a weighted formula. View count provides the base signal with weight 1.0. Likes indicate strong approval with weight 5.0. Comments show deep engagement with weight 10.0. Shares represent the highest endorsement with weight 20.0 since users are putting their reputation behind the content. Completion rate, measuring average watch time divided by video duration, multiplies the score by up to 50.0 for highly engaging content.

A time-decay factor ensures new content is favored. Videos lose score over time using the formula decay = 1.0 / (1.0 + age_hours / 2.0). This creates an exponential decay that dramatically reduces scores for videos more than a few hours old.

Trending scores are stored in Redis sorted sets, organized by category including global trending, regional trending for each geographic area, category trending for content types like comedy or cooking, and hashtag trending for each popular hashtag.

Retrieving the top 100 trending videos is a simple sorted set query that completes in milliseconds.

Viral Content Scaling:

When a video’s view rate crosses a threshold, typically one million views per hour, it triggers viral scaling procedures.

The video is immediately pushed to all CDN edge locations globally rather than relying on organic cache distribution. Cache TTL is increased from the default 1 hour to 24 hours to ensure availability. CDN bandwidth allocation is increased to handle the traffic surge.

Video metadata is cached in Redis with extended TTL, reducing database load. The database shifts to read-heavy replicas for metadata queries, with circuit breakers preventing cascading failures if the database becomes overloaded.

For engagement writes, the system switches to write batching, accumulating updates in memory and flushing to the database every 10 seconds rather than writing each action immediately. This reduces write QPS by 95% while displaying approximate counts to users. The counts converge to accuracy within a minute.

Auto-scaling triggers expand the video service horizontally, spinning up additional instances when CPU exceeds 70%. Database read replicas scale up when QPS crosses 10,000. CDN bandwidth alerts trigger at 80% capacity, notifying operations teams to add capacity or redistribute load.

Hashtag Trending:

A separate Flink job tracks hashtag usage. Events containing hashtags are extracted and counted over tumbling one-hour windows. The counts are stored in Redis sorted sets, enabling queries for top trending hashtags by region or globally.

Trending hashtags are promoted in the UI, encouraging users to explore related content and participate in trends. This creates positive feedback loops that accelerate viral distribution.

Deep Dive 5: How do we implement duets and stitches efficiently?

Duets and stitches are unique features that enable creative remixing of content. Duets display two videos side-by-side, with the original on one side and the user’s reaction on the other. Stitches concatenate a clip from the original video with new content. Both require server-side video composition.

Duet Implementation:

The user experience begins with the creator recording their reaction video while watching the original. The client app handles the timing synchronization, ensuring both videos start simultaneously. Once recording completes, both the original video ID and the new video file are sent to the server.

The server-side composition uses FFmpeg to create the side-by-side layout. The original video and new video are each scaled to half-width, typically 640 pixels if the output is 1280 pixels wide. They’re then horizontally stacked into a single output video. Both audio tracks are mixed, or the creator can choose to mute the original audio.

The composition job runs in the video processing pipeline just like a normal upload, transcoding the result to multiple resolutions. The output video includes metadata linking it to the original video for attribution.

Attribution is critical for creator rights. The duet video object stores a parent_video_id field referencing the original. The UI displays “Duet with @originalcreator” prominently. If the original creator has disabled duets in their settings, the duet creation is rejected.

For monetized content, revenue sharing agreements ensure the original creator receives a percentage of earnings from derivative works. This creates incentives for creators to allow remixing while protecting their intellectual property.

Stitch Implementation:

The stitch workflow begins with the user selecting a clip from the original video. The UI allows them to choose start and end timestamps, typically limited to 5 seconds. The clip selection is sent to the server along with the new video content.

Server-side processing extracts the selected clip from the original video using FFmpeg with precise timestamp parameters. The extracted clip is then concatenated with the new video, creating a seamless sequence. Audio from both segments is preserved or mixed according to creator preferences.

Like duets, attribution links the stitch to the original video. The UI displays “Stitched from @originalcreator” and provides a link to view the full original video. Creators can disable stitches in their settings.

Copyright and Rights Management:

The system uses a graph database like Neo4j to track derivative works. When a duet or stitch is created, an edge is added from the derivative to the original. This enables queries like “find all duets of this video” or “what’s the complete derivation chain.”

Licensing rules are enforced programmatically. The service checks if the original creator allows duets/stitches before permitting creation. Usage metrics track how many derivatives exist, feeding into analytics and potential revenue sharing.

DMCA takedowns that target an original video can cascade to derivatives, ensuring compliance with copyright law while minimizing manual moderation effort.

Deep Dive 6: How do we manage millions of audio tracks with licensing compliance?

Music and sounds are central to TikTok’s appeal, but they introduce complex licensing requirements. The platform must track audio usage, detect copyrighted material, enforce geographic restrictions, and calculate royalty payments.

Audio Fingerprinting:

When a video is uploaded, the processing pipeline extracts the audio track and generates an acoustic fingerprint using services like ACRCloud or Shazam. The fingerprint is a compact representation of the audio’s spectral characteristics, robust to noise and compression.

The fingerprint is compared against a database of known tracks, including licensed music in the platform’s library and copyrighted music reported by rights holders. If a match is found, the system checks licensing status.

For licensed content, the video is allowed with metadata linking it to the sound. For unlicensed copyrighted content, the video is either blocked, muted, or restricted to regions where licensing exists. For unrecognized audio, it’s treated as original content created by the user.

License Management:

The licensing database stores agreements with music labels and publishers. Each track has associated metadata including ISRC codes for unique identification, licensing regions where playback is permitted, usage limits if the agreement caps total plays, expiration dates for time-limited licenses, and royalty rates per play.

When a video using licensed music is played, an event records the play for royalty calculation. Aggregated monthly usage reports are generated for rights holders, and payments are issued based on negotiated rates.

Geographic Restrictions:

Some music licenses are region-specific. A video might be playable in the United States but blocked in Germany due to licensing limitations. The system enforces this by checking the user’s geographic location at playback time and filtering out videos with unlicensed audio for that region.

Creators receive notifications if their video is region-restricted, allowing them to replace the audio or accept limited distribution.

Sound Discovery and Search:

Trending sounds are identified by the analytics pipeline, counting usage over rolling time windows. The platform maintains a sound library where users can browse popular sounds, search by title or artist, and view videos using each sound.

Elasticsearch provides fast full-text search across sound metadata. Users can search by song title, artist name, or even lyrics. Results are ranked by relevance and popularity.

The sound page for each track shows usage statistics, trending trajectory, and example videos. Users can add the sound to their favorites for quick access during video creation.

Deep Dive 7: How do we provide real-time analytics to millions of creators?

Creators rely on analytics to understand what content resonates and grow their audience. Providing detailed, real-time metrics at scale requires a hybrid architecture combining streaming and batch processing.

Real-Time Metrics (Last 24 Hours):

Apache Flink processes engagement events from Kafka in real-time. For each video, it maintains counters for views, likes, comments, shares, and watch time using sliding windows. These metrics are aggregated every 5 minutes and written to Redis.

Per-creator aggregations sum metrics across all their videos. Follower growth is tracked by processing follow events. Engagement rate is calculated as total interactions divided by total views.

When a creator opens their analytics dashboard, the API reads recent metrics from Redis. The data is approximately 5 minutes old, which is acceptable for real-time monitoring. The dashboard shows current view velocity, helping creators understand if a video is gaining momentum.

Historical Analytics (Batch Processing):

For longer time ranges and deeper analysis, batch processing using Apache Spark runs nightly. The jobs read from a data warehouse like Snowflake that stores all historical events.

Spark jobs compute daily, weekly, and monthly rollups for each creator and video. They calculate advanced metrics like audience demographics from user profiles, geographic distribution of views, retention curves showing drop-off points in videos, and traffic sources tracking how viewers discovered content.

These pre-computed reports are stored in MongoDB or another document database. The analytics API reads from this store for historical queries, providing fast responses without recomputing on demand.

Optimization Techniques:

For mega creators with millions of followers and videos, full computation would be too expensive. Sampling techniques analyze a statistically significant subset, typically 10%, and extrapolate results. The error margin is displayed to creators.

Pre-aggregation at multiple time granularities avoids repeated computation. Hourly, daily, and monthly rollups are computed once and stored. Range queries combine these pre-computed values.

Caching with 5-minute TTL in Redis reduces database load for frequently accessed dashboards. Popular creators checking their analytics multiple times per hour benefit from cached data.

The system also rate-limits analytics API calls, preventing abuse and ensuring resources are fairly distributed across all creators.

Step 4: Wrap Up

Designing TikTok requires balancing numerous technical challenges including massive video processing, personalized recommendations, real-time engagement tracking, viral content scaling, and complex content creation features. The architecture demonstrates key principles of modern distributed systems: horizontal scalability, eventual consistency where appropriate, specialized data stores for specific use cases, and machine learning integration for personalization.

Technology Stack Summary:

The frontend utilizes React Native for cross-platform mobile apps with native modules for video recording, Swift for iOS-specific features and optimizations, Kotlin for Android-specific implementations, and React with Next.js for web. Video playback leverages ExoPlayer on Android, AVPlayer on iOS, and Video.js on web, all supporting adaptive bitrate streaming.

Backend services are built with Go for high-performance video services, Node.js for real-time features and WebSocket connections, Python with FastAPI for ML service APIs, and Java for Kafka consumers and Flink jobs. Video processing uses FFmpeg for transcoding and composition, AWS MediaConvert for cloud-scale transcoding, and GPU-accelerated encoding for performance.

The machine learning stack includes TensorFlow and PyTorch for model training, TensorFlow Serving and TorchServe for model deployment, feature stores like Feast for online feature retrieval, and vector databases like Pinecone or Milvus for embedding search.

Data storage employs PostgreSQL for user data and video metadata with read replicas, Cassandra for the social graph and engagement data due to write scalability, MongoDB for comments and analytics reports, Redis for caching and trending data, and Elasticsearch for full-text search across videos and sounds.

Streaming infrastructure uses Kafka for event streaming and message durability, Apache Flink for real-time analytics and trending detection, and Apache Spark for batch processing and historical analytics.

Storage and delivery utilize Amazon S3 for object storage with intelligent tiering, CloudFront and Akamai for global CDN distribution, and origin shield for cost optimization.

Trade-offs and Considerations:

The architecture makes several key trade-offs. For consistency versus availability, engagement metrics use eventual consistency, allowing slightly delayed counts in exchange for higher availability and performance. Users tolerate seeing 100 likes that might actually be 103, but they won’t tolerate a failed like action.

Cost versus performance is a constant balance. Video storage and bandwidth dominate operational costs. Solutions include intelligent tiering that moves cold content to cheaper storage, lazy transcoding that defers resolution generation until demand, and CDN optimization with origin shield reducing redundant origin requests. These techniques achieve 40% cost reduction without impacting user experience.

Personalization versus diversity presents a challenging trade-off. Over-optimized personalization creates filter bubbles where users see only similar content. The solution injects 10% exploration content with diverse perspectives, applies diversity constraints in re-ranking, and occasionally surfaces trending content outside user interests. This maintains engagement while promoting creator growth and cultural relevance.

Real-time versus batch processing uses a hybrid approach. Trending detection and engagement updates require real-time processing for immediate feedback loops. Analytics, historical reports, and less time-sensitive features use batch processing for efficiency. This optimizes resource utilization and cost.

Scaling Considerations:

Database sharding partitions data for horizontal scalability. The User Service shards by user_id using consistent hashing, the Video Service shards by video_id, and the Social Graph shards by user_id with read replicas handling follow queries. Cross-shard operations are minimized through careful schema design.

The caching strategy employs multiple layers with different TTLs. User sessions persist for 24 hours, video metadata for 1 hour, feed cache for 5 minutes, and trending data updates every minute. Cache invalidation on writes ensures consistency for critical data.

CDN strategy uses multi-CDN deployment with both Cloudflare and Akamai for redundancy and geographic coverage. Edge caching at over 200 locations provides sub-100ms latency for most users. Origin shield reduces origin requests by 80%, significantly lowering bandwidth costs.

Monitoring and Observability:

Key metrics tracked include video upload success rate targeting over 99%, video processing time targeting under 2 minutes, feed load time targeting under 500ms, video start time targeting under 200ms, API error rate targeting under 0.1%, and CDN cache hit rate targeting over 95%.

Alerting triggers on upload service degradation, ML model serving latency spikes, database connection pool exhaustion, Kafka consumer lag exceeding 1 minute, and CDN bandwidth approaching saturation. Operations teams respond to alerts with runbooks for common issues.

Security Considerations:

Content security implements ML-based video moderation to detect policy violations, user-generated content filtering, CSAM detection with NCMEC reporting compliance, and copyright infringement detection through audio fingerprinting.

Data privacy compliance includes GDPR with data deletion and portability rights, COPPA with age verification for users under 13, encryption at rest and in transit using TLS 1.3, and PII anonymization in analytics to protect user identity.

Access control uses OAuth 2.0 for authentication, JWT tokens with short TTL and rotation, role-based access control for internal tools, and rate limiting per user and IP address to prevent abuse.

Future Enhancements:

Technical improvements on the roadmap include edge computing for video processing to reduce latency by 50%, WebRTC for live streaming with lower latency than traditional protocols, WebAssembly for in-browser video editing without uploads, and GraphQL for flexible API queries reducing over-fetching.

Product features in development include advanced AR filters and effects using face tracking, live shopping and e-commerce integration, multi-camera angles for live streams, collaborative videos with three or more people, and video chapters with timestamps for longer content.

ML and AI enhancements leverage GPT-based caption generation to improve accessibility, auto-translation for global reach, voice cloning for dubbing content across languages, and deepfake detection to combat misinformation.

This comprehensive design provides a production-grade architecture for TikTok, capable of handling billions of users with personalized content delivery, real-time engagement, and viral content distribution at massive scale. The system demonstrates how modern cloud infrastructure, machine learning, and distributed systems principles combine to create compelling user experiences while managing complexity and cost.