System Design Interview: TikTok Architecture

Designing a massive short-form video platform like TikTok or Instagram Reels requires handling millions of daily active users, massive video ingestion, heavy background transcoding pipelines, global multi-region replication, and ultra-low latency content delivery. This note breaks down a live mock system design interview between GKCS and Yogita Sharma (creator of SudoCode).

1. Problem Overview & Functional Requirements

The core objective is to design a distributed short-form video sharing platform where users around the world can upload, store, and stream short videos on their newsfeeds.

• Functional Requirements:
  • Video Upload: Creators can upload short-form videos with metadata (title, description, thumbnail).
  • Video Storage: Systems must durably and securely store raw and processed video files.
  • Video Distribution & Streaming: Viewers can fetch feeds, view creator profiles, and stream videos globally with low latency.
• Scope Clarification:
  • Video length is strictly capped at 60 seconds (defaulting primarily to 7-10 second clips in typical use cases).
  • Real-time instant propagation is not strictly required; an asynchronous delay of a few minutes between upload and global visibility is acceptable.

2. Non-Functional Requirements & Core Trade-Offs

When designing at web scale, certain trade-offs must be established immediately to guide architectural decisions.

• High Availability & Fault Tolerance: The system must remain resilient against localized failures. If a data center or region goes down, it should not disrupt global business operations.
• Low Latency Performance:
  • Upload Path: Creators should experience fast uploads without being bottlenecked or waiting synchronously for video processing to finish.
  • Streaming Path: End-users must experience zero stuttering and low latency when playing video streams.
• Consistency vs. Availability (CAP Theorem):
  • Eventual Consistency is heavily favored over strict consistency. If a video takes 30 seconds to replicate across regions or appear in secondary feeds, it is entirely acceptable.
  • Availability and Partition Tolerance (AP) are prioritized over immediate global consistency.

3. Scale Estimation & Read/Write Ratios

Before diving into components, napkin math establishes the system's sizing constraints.

• Daily Active Users (DAU): Assume 1 billion total app downloads, with 10% DAU = 10 million active viewers.
• Active Creators: Assume 1% of viewers create content = 100,000 creators (100K) posting daily.
• Read-to-Write Ratio:

• Daily Storage Calculation:
  • Assume 200,000 uploads per day (some creators upload multiple times).
  • Average video size = 1 MB (short 7-10 second clips).
  • Raw daily storage: $200,000 \times 1\text{ MB} = 200\text{ GB/day}$.
  • Factoring in multiple resolutions and formats (multiplied by ~3x for transcoding variants):

• Conclusion: 1.2 TB/day is easily manageable for modern cloud infrastructure or dedicated bare-metal data centers.

4. High-Level Monolithic Evolution to Microservices

A standard best practice in system design interviews is to start with a simplified monolithic mental model and progressively decouple components into specialized microservices.

As scale increases, the monolith is split into specialized decoupled services:

1. Ingest / Onboarding Service: Handles incoming creator video uploads and delegates heavy lifting to a background worker queue.
2. Video Serving Service: Resolves user geolocation, device specs, network bandwidth, and fetches appropriate video streams from global storage/CDNs.

5. Storage Strategy & Database Selection

Different data characteristics require tailored storage solutions.

6. Asynchronous Ingestion & Transcoding Pipeline

To prevent blocking creators during upload and to support hundreds of diverse client devices (iOS, Android, web, various screen resolutions), incoming videos must undergo heavy asynchronous processing.

Why Chunking and Parallelism Matter

• Short videos ($\le 10$ seconds) are processed directly.
• Longer videos are split into temporal chunks so that worker nodes can process different chunks in parallel across a distributed worker pool.
• Adding support for a new device resolution or video format in the future only requires adding a new worker step in the modular pipeline.

7. Global Distribution & CDN Architecture

Serving millions of concurrent viewers globally without high latency requires pushing content to the edge of the network.

• Amazon S3 + CDN Integration: Raw files stored in S3 are replicated across multiple global AWS regions (e.g., US, Europe, Asia).
• Content Delivery Networks (CDNs): Leveraging CDNs like Akamai or building custom edge caches (similar to Netflix Open Connect) ensures that popular "hot" videos are cached close to the physical location of the user.
• Fault Tolerance: If an entire data center or region experiences an outage, DNS routing automatically fails over viewer requests to the nearest healthy regional replica.

8. End-to-End Read Flow: Fetching a User's Feed

When a viewer opens their profile or requests a creator's video feed, the read path executes as follows:

9. Interviewer Feedback & Key Learnings

At the conclusion of the mock interview, the interviewer highlighted critical evaluation criteria for system design interviews:

• What Went Well:
  • Decoupling Ingestion & Processing: Using a message queue and worker pipeline successfully decoupled the upload rate from the transcoding rate, protecting the system from traffic spikes during peak holidays.
  • High Availability & Fault Tolerance: Proper use of S3 replication, multi-region architecture, and CDNs.
  • Appropriate Database Choices: Matching relational data to MySQL, flexible attributes to MongoDB, and binary files to S3.
• Areas for Improvement:
  • Cost Estimation: Address cost implications and bandwidth/storage economics earlier in the interview when discussing large-scale cloud object storage and multi-region replication.
  • Network Protocols: Be prepared to discuss transport layers (e.g., HTTP/2, TCP vs. UDP/QUIC for streaming) with confidence, or clearly articulate boundaries when unfamiliar rather than hesitating.

10. Summary and Key Takeaways

• Isolate the Ingest Path: Always use async queues (Ingest API -> Queue -> Workers) for heavy background processing tasks like video transcoding to keep user-facing upload latency minimal.
• Prioritize Eventual Consistency: For media streaming and social feeds, favor high availability and partition tolerance (AP) over strict immediate consistency.
• Leverage Object Storage & CDNs: Pair cloud object storage (S3) with global CDNs to offload traffic and achieve low-latency video streaming worldwide.
• Modular Transcoding Pipelines: Split video processing into chunking, format conversion, and resolution scaling stages executed across parallel worker pools for infinite horizontal scalability.
• Flexible Metadata Stores: Use NoSQL document/key-value stores for video metadata to accommodate flexible, evolving schemas over time.
• Right Database for the Job: Never force a single database type; match relational entities (users, relationships) to SQL and unstructured or flexible attributes to NoSQL.
• Design for Failure: Ensure multi-region replication and fault-tolerant routing so that regional server outages do not cause global system failure.
• Proactive Cost & Bandwidth Analysis: Anticipate infrastructure costs early in high-scale storage designs involving multi-bitrate and multi-resolution file proliferation.