Designing TikTok : A System Design Guide for SDE3 & Staff Software Engineer Interviews

Designing TikTok : A System Design Guide.

“TikTok isn’t just a video streaming application. It’s one of the world’s largest recommendation engines disguised as a social media app.”

If you’ve ever appeared for an SDE3, Senior Software Engineer, or Staff Engineer interview, chances are you’ve encountered a system design question around YouTube, Instagram Reels, or TikTok.

At first glance, the problem looks deceptively simple: users upload videos, and other users watch them.

But once you start designing the system, you quickly realize that video storage is actually one of the easier problems. The real challenge lies in delivering the right video to the right user within milliseconds, while supporting billions of users worldwide.

In this article, we’ll design a platform similar to TikTok from scratch. Instead of jumping directly into databases or microservices, we’ll think like an engineer designing a production-ready system — understanding the business requirements, identifying the technical challenges, and gradually building an architecture that can scale to hundreds of millions of users.

Understanding the Problem

Before drawing architecture diagrams, let’s understand what TikTok actually does.

From a user’s perspective, TikTok offers only a handful of features:

• Upload short videos
• Watch videos
• Scroll endlessly through the “For You” feed
• Like, comment, and share videos
• Follow creators
• Search for videos and hashtags
• Receive notifications

Sounds simple, right?

Now imagine supporting these features for 500 million daily active users. Every second, thousands of users upload videos, while millions of others continuously swipe through their feeds. Every swipe triggers a recommendation request. Every like, comment, and share generates new data that immediately influences future recommendations.

This is why TikTok is fundamentally three systems working together:

1. A large-scale video hosting platform.
2. A real-time recommendation engine.
3. A global content delivery network.

Most interview candidates spend 80% of their time discussing video storage. In reality, experienced interviewers are often more interested in how you design the recommendation pipeline, event processing, caching, and scalability.

Functional Requirements

The system should support:

• Upload — users upload videos from their mobile devices, which are then processed, stored, and eventually made available for others to watch.
• Infinite feed — scroll through a “For You” feed where every swipe loads the next recommended video.
• Like, comment, share — interact with videos and share them with friends.
• Follow — follow creators.
• Search — find videos using hashtags or captions.
• Notifications — get notified whenever someone interacts with their content.

Although these features appear independent, they’re actually connected. A single “Like” action doesn’t just increase a counter — it also becomes a signal that helps the recommendation system understand the user’s interests.

Non-Functional Requirements

You’re expected to discuss not only what the system does, but also how well it performs:

• High Availability — Even if one data center goes offline, users should still be able to watch videos.
• Low Latency — The next video should appear almost instantly; a one-second delay per swipe tanks engagement.
• Scalability — The system should grow from one million users to several billion without major architectural changes.
• Durability — Once a creator uploads a video, losing it is unacceptable. Videos should be replicated across multiple storage systems.
• Reliability — Temporary failures should not crash the application. If one service fails, the rest of the platform should keep functioning.

Estimating the Scale

Let’s make some assumptions:

• 500 million daily active users
• Each user watches ~200 videos every day
• ~10 million videos uploaded daily
• Average uploaded video size: 20 MB

That’s nearly 100 billion feed requests every day — more than one million feed requests every second at peak. Meanwhile, 10 million uploads × 20 MB is roughly 200 TB of raw video every day, and that grows further once multiple resolutions (1080p, 720p, 480p) are generated.

TikTok is a read-heavy system. Uploads are small compared to the enormous volume of consumption happening every second.

High-Level Architecture

When engineers first look at a system like TikTok, it’s easy to focus on the number of microservices or technologies used. In reality, the architecture is driven by a simpler principle: keep user-facing operations fast, and move expensive work into the background.

A creator uploading a video shouldn’t have to wait while the platform transcodes resolutions, scans for inappropriate content, generates thumbnails, extracts captions, and updates search indexes — none of that needs to finish before the upload request returns successfully. That heavy work happens asynchronously through Kafka instead.

You’ll see this pattern repeated throughout this design: lightweight synchronous APIs handle user interactions, while Kafka-powered background pipelines do the heavy lifting.

1. API Layer — Every request first reaches the Global Load Balancer, then the API Gateway, which authenticates, rate-limits, logs, and routes to the right microservice.

2. Core Business Services — Each owns one capability: Upload Service (accepts uploads), Feed Service (personalized feed), User Service (profiles/followers), Search Service (videos/hashtags/creators), Notification Service (push/in-app alerts). Independent services scale independently.

3. Event Streaming (Kafka) — When a user uploads a video, Upload Service publishes a VideoUploaded event. Transcoding, AI Moderation, Analytics, and Search all consume it independently, reducing coupling.

4. Video Processing Layer — Transcoding, thumbnail generation, AI moderation, speech-to-text, OCR, copyright detection, and metadata extraction all happen in the background while the upload API has already returned.

5. Storage Layer — Processed videos live in Object Storage; metadata (titles, captions, creator info) lives in databases. Separating the two improves performance and scaling.

6. CDN Layer — Videos are served through a Global CDN so users get content from the nearest edge server instead of a distant origin.

7. Shared Infrastructure — Redis (caching sessions/feeds/metadata), MySQL/PostgreSQL (relational user data), Cassandra/DynamoDB (high-write likes/views/comments), Elasticsearch/OpenSearch (full-text search).

8. Recommendation Platform — The most critical component. Rather than showing videos chronologically, it builds a personalized feed via candidate generation → feature extraction → ML ranking → feed generation. The Feed Service requests ranked videos from here before returning them to the app.

Interview Tip (Staff Level): Emphasize that the recommendation platform — not video storage — is TikTok’s core differentiator. Most large companies can build scalable storage and delivery; TikTok’s edge is its low-latency, ML-driven recommendation engine that continuously learns from billions of interactions.

The Video Upload Journey

Many beginners assume the mobile app uploads the video directly to the backend server. That works for a small app but becomes extremely expensive at TikTok’s scale — millions of users uploading 100 MB videos simultaneously would turn application servers into network bottlenecks.

Instead, TikTok’s mobile app first sends a lightweight request to the Upload Service asking for permission to upload. The Upload Service authenticates the user, validates upload limits, and generates a pre-signed upload URL. The app then uploads the video directly to object storage using that temporary URL — never touching the application servers.

This keeps application servers off the critical path entirely: uploads are faster because storage systems are optimized for large objects, and backend services stay lightweight enough to handle far more concurrent users.

Once the upload finishes, object storage notifies the Upload Service that a new video has arrived, and the creator sees: “Your video is being processed.” The video isn’t public yet — several downstream pipelines still need to run.

Video Processing Pipeline

Uploading a video is only the beginning. The raw file from a phone is usually too large and unsuitable for streaming directly, so a processing pipeline kicks off automatically in the background:

1. Transcoding — converted into multiple resolutions (1080p, 720p, 480p, 360p) so slower connections can watch without buffering.
2. Thumbnail generation — so users can preview before opening.
3. Speech-to-text — helps with captions, accessibility, and search.
4. AI moderation — frame analysis detects nudity, violence, or copyrighted material.
5. Audio fingerprinting — identifies copyrighted music.
6. OCR — extracts any text appearing inside the video.

Only after all of these succeed does the system mark the video ready for public viewing. Crucially, this is asynchronous — the creator doesn’t wait for AI analysis to finish before the upload request returns; background workers process the video independently.

Managing Video Metadata

While the video itself is a large binary object sitting in object storage, the platform also needs a lightweight, fast-to-query representation of it: metadata. This typically includes the creator ID, caption, hashtags, upload timestamp, privacy settings, video duration, thumbnail location, references to every transcoded version, and running counters like view/like/comment counts.

Storing this separately from the binary matters for one simple reason: reading a few kilobytes from a database is far faster than reading an entire video file. Almost every service depends on metadata rather than the video itself — Feed Service needs creator, thumbnail, duration, hashtags, and engagement stats; Search Service indexes captions and hashtags; Notification Service uses metadata to notify followers. Only when a user actually presses Play does the app start pulling the video from the CDN.

Keeping metadata lightweight and separate lets it scale independently — millions of metadata queries happen every second, while the underlying video files are accessed through the CDN instead.

Kafka: The Backbone of Asynchronous Processing

A common interview question: “How do all these downstream services know a new video has been uploaded?”

Instead of calling every service synchronously, Upload Service publishes an event to Kafka — think of it as a central event bus:

Video Uploaded
Video ID: 987654
User ID: 12345

Different services subscribe independently: Transcoding starts conversion, AI Moderation begins content analysis, Search indexes captions, Analytics records upload metrics, Notification informs followers when appropriate.

Upload Service doesn’t need to know whether there are five downstream consumers or fifty — it publishes and moves on. This loose coupling is one of the key principles of scalable distributed systems. If the team later adds a new pipeline (say, automatic subtitle generation), they don’t touch Upload Service at all — the new service just subscribes to the existing VideoUploaded event. As the system grows from a handful of consumers to dozens, Kafka keeps acting as the backbone without adding complexity to the upload workflow.

At this point, the video has been processed, transcoded, moderated, indexed, and its metadata created. It’s now eligible to appear in feeds.

The Recommendation Engine: TikTok’s Secret Sauce

If I had to describe TikTok in one sentence: TikTok is a recommendation engine that happens to stream videos.

Every interaction becomes a signal. Watching a full video is positive feedback; replaying it is stronger still. Liking, commenting, sharing, following, even visiting a creator’s profile all shape your interest profile — and so does swiping away quickly, which signals irrelevance.

Here’s the key reframe: the recommendation engine doesn’t ask “which video is most popular?” — it asks “which video is this user most likely to watch, enjoy, and keep engaging with right now?” That distinction is what makes the feed feel personalized. Out of a billion videos, TikTok uses multiple stages that progressively narrow the search space before expensive ranking models get involved.

Stage 1: Candidate Generation

With a billion videos, no ML model can score everything for every user in real time. So the first step retrieves a few thousand candidates from multiple sources:

• Videos from creators the user follows
• Trending videos in the user’s region
• Recently uploaded content
• Videos similar to previously watched videos
• Videos liked by users with similar interests
• Videos matching the user’s embedding
• Exploration content introducing new creators

Nothing is ranked yet — this is a shortlist, not an interview.

Stage 2: Filtering

The candidate list still has thousands of videos, and not all of them belong in front of the user. Filtering removes:

• Videos already watched recently
• Videos from blocked users
• Duplicate uploads
• Age-restricted content
• Videos removed by moderation
• Content unavailable in the user’s country
• Videos with very poor quality scores

Stage 3: Machine Learning Ranking

The most computationally expensive stage. Each remaining video is scored using hundreds of features: watch time percentage, completion rate, rewatch count, like/share/comment/follow probability, freshness, creator quality, device type, network speed, time of day, language, region, and more.

A simplified version of the final score:

Final Score =
  0.35 × Watch Time
+ 0.25 × Completion Rate
+ 0.15 × Share Probability
+ 0.10 × Like Probability
+ 0.10 × Follow Probability
+ 0.05 × Freshness

Production systems use deep learning models instead of a linear equation, but the idea holds: the top-ranked videos become the next feed.

Watch Event Processing

TikTok learns far more from what users do than what they explicitly say — most people rarely hit Like, but everyone watches videos. As soon as playback starts, the app sends lightweight interaction events: when playback started, how long the user watched, whether they replayed, paused, or swiped away quickly.

Same fan-out pattern as before: these events go to Kafka once, and Analytics, the Recommendation Platform, the Trending Service, and ML pipelines all consume the same stream independently — Analytics measuring engagement, Recommendation updating preferences, Trending spotting rapidly growing content.

Why Does TikTok Feel So Addictive?

If the recommendation engine only showed you cooking videos because you’ve watched them before, your feed would eventually become repetitive. So TikTok intentionally injects a small percentage of random or exploratory content — maybe travel videos or stand-up comedy — and if you engage, the engine learns a new interest. This exploration vs. exploitation balance is why the feed keeps introducing fresh content instead of looping the same categories.

Infinite Scrolling

The recommendation engine rarely returns a single video — it generates a small ranked batch. As the user consumes it, the app quietly requests the next batch once only a few videos remain.

Instead of page numbers, Feed Service returns a cursor with each response. The client sends that cursor back to fetch more, letting the engine continue from the right position while incorporating the user’s latest interactions. This works far better than page-based pagination, since recommendations are constantly evolving.

Feed Prefetching

TikTok doesn’t wait until you finish the current video to prepare the next one. While you’re still watching, the app quietly downloads metadata and buffers the next few recommended videos in the background — so by the time you swipe, the next video is often already available or partially buffered from the nearest CDN edge.

This hides network latency and creates TikTok’s signature smooth scroll. The client balances this against wasted bandwidth by only prefetching a small number of upcoming videos.

Delivering Videos with a CDN

At this point, Feed Service has selected the next batch. Should every playback request travel back to the primary object storage? Definitely not — imagine a celebrity’s video going viral: millions of users across countries requesting the exact same content within minutes would overload any origin store.

Instead, TikTok places a Content Delivery Network (CDN) between users and object storage — thousands of edge servers worldwide. A user in Bangalore is served from the nearest edge location instead of a distant data center, cutting latency and origin bandwidth. Popular videos stay cached close to users, so millions of playback requests never touch the original file.

One more optimization: TikTok caches video segments, not whole files. Since video is streamed via adaptive bitrate protocols like HLS or MPEG-DASH, each video is chunked into small segments — if a user’s network slows down, the player just requests lower-quality segments without restarting playback.

Putting the full request together:

1. The app requests the next recommended video.
2. Feed Service returns video metadata plus a CDN URL.
3. The player contacts the nearest CDN edge server.
4. If the segments are already cached at the edge, they stream immediately.
5. Otherwise, the CDN fetches from origin storage, caches locally, and streams back.
6. Future viewers in that region now get the cached version directly from the edge.

This caching strategy keeps latency low while protecting origin storage from viral traffic spikes.

Why Redis Is Everywhere

If a viral video suddenly gets 50 million views in an hour, hitting the database for every view-count read would create a bottleneck. So TikTok leans heavily on Redis — caching user profiles, feed pages, video metadata, trending hashtags, like counts, and session data in memory, where reads typically take under a millisecond. The database stays the source of truth; Redis is the high-speed layer in front of it.

Different services cache different things based on their own access patterns: Feed Service caches recent recommendation results, User Service caches profiles and sessions, Search Service caches frequently searched hashtags, and the Recommendation Platform caches feature vectors used during online inference. Whenever underlying data changes, cache entries are updated or invalidated so users eventually see fresh data without sacrificing speed.

Search Service

Users search by hashtags, captions, or creator names. Querying relational databases directly for this gets expensive fast, so TikTok maintains a dedicated search index instead.

Search Service is one more consumer of the VideoUploaded event: it extracts captions, hashtags, OCR text, speech-to-text transcripts, and creator info, then indexes all of it into Elasticsearch or OpenSearch. A user’s search hits that index instead of scanning millions of database rows — keeping response times fast as the platform grows.

Notifications

When someone likes your video or follows you, the Like Service doesn’t fire a push notification directly — it publishes a Kafka event, same as everywhere else in this design, and the Notification Service consumes it asynchronously.

Likes, comments, shares, and follows are actually some of the highest write traffic on the platform, and each publishes its own event for a slightly different set of consumers to pick up: Analytics dashboards, Recommendation model updates, Trending detection, Notification delivery, and fraud detection systems watching for suspicious activity.

What this buys you here specifically: likes stay fast regardless of notification load, a failed notification never affects the Like API and can simply be retried later, and multiple notification channels (push, in-app, email) subscribe independently without adding latency to the original interaction.

Handling Failures Gracefully

No production system is perfect — servers crash, databases become unavailable, Kafka brokers fail, entire regions can go offline. A Senior Engineer isn’t expected to eliminate failures; they’re expected to design systems that keep working despite them.

If Redis crashes, Feed Service can temporarily fall back to the database (slower, but functional). If the recommendation service is unavailable, TikTok can serve a cached feed instead of an error. If one CDN provider has issues, traffic redirects to another. If the transcoding pipeline is overloaded, newly uploaded videos simply stay in “Processing” until workers catch up.

The philosophy: a degraded experience beats no experience at all.

Failure Isolation

This is the same principle at the service-boundary level: a problem in one service shouldn’t bring down the rest of the platform. If Search goes down, only search breaks — watching, scrolling, uploading, and liking all keep working, since nothing else depends on it.

Circuit Breakers and Timeouts

When a downstream service gets slow, upstream services shouldn’t wait indefinitely — requests use timeouts and circuit breakers instead. After repeated failures, the circuit breaker stops sending requests to the unhealthy service and returns a fallback immediately, rather than letting thousands of threads block. This protects the rest of the platform from cascading failures and helps the system recover faster once the unhealthy service comes back.

Scaling Independently

As TikTok grows, every component scales on its own schedule, not in lockstep — because they don’t grow at the same rate. Upload Service only sees high traffic when creators publish; Feed Service gets hit almost every swipe; Kafka adds partitions as events grow; Redis clusters expand; object storage grows near-infinitely; CDN providers add edge locations automatically. The Recommendation Platform is the heaviest of all, burning enormous compute since every feed request needs fresh candidate generation and ranking. Scaling each service independently lets engineering teams put resources where they’re actually needed instead of scaling the whole application together — cutting infrastructure cost while letting each piece evolve on its own.

Database Scaling

Different data needs different strategies. Relational databases (MySQL/PostgreSQL) suit user accounts, auth data, creator profiles, and video metadata. High-write workloads like likes, views, and comments benefit from distributed databases (Cassandra/DynamoDB) built for massive write throughput. Read replicas help with frequently accessed relational data, and sharding kicks in once a single database can’t handle the load. Picking the right storage technology per workload beats forcing everything through one database.

Kafka Scaling

As uploads and interactions grow, Kafka scales by splitting topics into multiple partitions that process in parallel, and by adding consumers to consumer groups as traffic increases — all without changing the producing services. This makes Kafka a natural fit for platforms with millions of interactions per second.

CDN Scaling

Not every video gets the same traffic — most are viewed a handful of times, a few go globally viral. CDN providers automatically replicate popular content across more edge locations as demand rises, and evict less-accessed videos over time to free up space for newer or more popular content — all without manual intervention.

Conclusion

TikTok appears simple from the outside: users upload videos, users watch videos, users keep scrolling. Behind that simplicity sits one of the world’s most sophisticated distributed systems.

What makes TikTok remarkable isn’t its ability to store videos — many companies can build scalable storage. Its true edge is delivering the right video to the right user within milliseconds, while continuously learning from billions of interactions happening across the platform every single day.

And that’s exactly what makes TikTok one of the most fascinating system design problems for software engineering interviews.