Bird
Raised Fist0

Design TikTok - Short Video Upload, For-You Feed Algorithm, Creator Stack

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
Upload Proxy

Receives video upload from user

Accepts raw video file and metadata

Protocol:HTTP POST
BeforeUser has raw video file ready to upload
AfterUpload Proxy has received raw video and metadata
Transcoding Service

Transcodes raw video to multiple formats

Converts video for compatibility and streaming

Protocol:RPC call from Upload Proxy
BeforeRaw video stored temporarily in Upload Proxy
AfterTranscoded video files generated and ready
Video Storage

Stores transcoded video files durably

Persists video files for later streaming

Protocol:RPC call from Transcoding Service
BeforeTranscoded video files exist in Transcoding Service
AfterVideo files stored durably and accessible
Metadata DB

Stores video metadata and indexing info

Records video info for search and feed

Protocol:Event triggered RPC from Video Storage
BeforeVideo files stored but metadata not updated
AfterMetadata DB updated with new video info
For-You Feed Generator

Computes personalized feed including new video

Fetches user profile and ranks videos

Protocol:RPC call to User Profile Service
BeforeMetadata DB has new video info, feed outdated
AfterFeed updated with new video recommendations
User Profile Service

Returns user preferences and history

Supports feed personalization

Protocol:RPC response to For-You Feed Generator
BeforeUser profile data stored and accessible
AfterUser profile data delivered for feed computation
Delivery CDN

Delivers video streams to user devices

Serves video URLs from feed

Protocol:HTTP streaming
BeforeFeed Generator has video URLs ready
AfterUser receives video streams with low latency
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Upload Proxy  │
└───────┬───────┘
        │ HTTP POST (video upload)
        ▼
┌───────────────────────┐
│ Transcoding Service   │
│ (video format convert)│
└─────────┬─────────────┘
          │ RPC (store transcoded video)
          ▼
    ┌─────────────┐
    │ Video       │
    │ Storage     │
    └─────┬───────┘
          │ Event (video ready)
          ▼
┌───────────────────────┐
│ Metadata DB           │
│ (video metadata store)│
└─────────┬─────────────┘
          │ RPC (update metadata)
          ▼
┌─────────────────────────────┐
│ For-You Feed Gen.            │
│ (personalized feed comp.)    │
└─────────────┬───────────────┘
              │ RPC (fetch user profile)
              ▼
      ┌───────────────────┐
      │ User Profile      │
      │ Service           │
      └─────────┬─────────┘
                │ RPC (deliver feed video URLs)
                ▼
         ┌───────────────┐
         │ Delivery CDN  │
         │ (video delivery)│
         └───────────────┘
Design Rationale

This architecture shows the vertical flow of a TikTok short video upload and feed generation. The Upload Proxy accepts raw videos, which the Transcoding Service converts into multiple streaming formats. These files are stored durably in Video Storage. Once stored, Metadata DB is updated to index the new video. The For-You Feed Generator then computes personalized feeds by querying the User Profile Service for preferences and history. Finally, the Delivery CDN streams videos efficiently to users. This vertical design ensures clear separation of concerns and scalability, with asynchronous updates between storage and feed generation enabling low-latency user experiences.

Primary Focus

✓

Practice

(1/5)
1. In a pub-sub system, at step 4 the Delivery Worker reads a message from the topic partition and checks the subscriber's offset. What happens if the subscriber's offset is behind the latest committed offset?
easy
A. The Delivery Worker deletes the message from the topic partition
B. The Delivery Worker skips the message and moves to the next one
C. The Delivery Worker delivers the message to the subscriber and updates the offset
D. The Delivery Worker blocks until the subscriber catches up

Solution

  1. Step 1: Understand subscriber offset semantics

    The subscriber offset tracks the last consumed message. If behind, the Delivery Worker must deliver pending messages to catch up.

  2. Step 2: Delivery Worker behavior

    It delivers the message at the subscriber's offset and then updates the offset to the next message. Skipping or deleting messages (Options A and C) breaks delivery guarantees. Blocking (The Delivery Worker blocks until the subscriber catches up) is unnecessary and stalls the system.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Delivery Worker delivers and advances subscriber offset [check]
Hint: Subscriber offset behind -> deliver message and update offset [check]
Common Mistakes:
2. If the API Gateway's authentication service crashes, what is the immediate failure mode observed by clients attempting to access protected endpoints?
medium
A. Clients receive a 500 Internal Server Error due to gateway crash
B. Clients receive a 401 Unauthorized response because authentication cannot be verified
C. Requests bypass authentication and reach backend services unverified
D. Requests queue indefinitely at the gateway until authentication service recovers

Solution

  1. Step 1: Trace failure impact of authentication service crash

    Without the authentication service, the gateway cannot verify credentials and may default to allowing requests through if no fail-closed mechanism is implemented.

  2. Step 2: Evaluate other options

    Clients receive a 500 Internal Server Error due to gateway crash is unlikely as gateway remains up. Clients receive a 401 Unauthorized response because authentication cannot be verified requires fail-closed design, which is not always implemented. Requests queue indefinitely at the gateway until authentication service recovers causes indefinite blocking, which is rare.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Auth service down -> requests pass unverified if no fail-closed [check]
Hint: Auth crash -> requests may bypass if no fail-closed design [check]
Common Mistakes:
3. If the Bloom filter's hash functions are not independent and produce correlated outputs, what is the exact failure mode observed?
medium
A. The bit array will saturate quickly causing excessive false positives and reduced filter effectiveness
B. The filter will have false negatives, incorrectly rejecting existing members
C. The false positive rate increases beyond the expected theoretical rate
D. Insertions will fail silently without updating the bit array

Solution

  1. Step 1: Understand hash function independence role

    Independent hash functions distribute bits uniformly; correlated hashes cause clustering.

  2. Step 2: Trace effect of correlated hashes

    Correlated hashes set overlapping bits, saturating the bit array faster, increasing false positives and reducing filter effectiveness.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Correlated hashes cause bit array saturation, raising false positives [check]
Hint: Correlated hashes cause bit array saturation and false positives [check]
Common Mistakes:
4. If the Booking Service loses connectivity to the Calendar Availability Service during booking confirmation, what is the most likely failure mode experienced by the user?
medium
A. The booking is queued locally and confirmed later without user notification
B. The booking request times out and the user sees an error without confirmation
C. The booking is confirmed but the calendar is not updated, causing double bookings
D. The system automatically retries and confirms booking without user delay

Solution

  1. Step 1: Trace failure impact on booking flow

    Loss of connectivity prevents immediate calendar update, risking inconsistency.

  2. Step 2: Analyze failure handling

    Immediate confirmation without calendar update (A) risks double bookings; timeout with error (B) hurts UX; automatic retry without delay (D) is unrealistic under network failure. Local queuing (C) allows eventual consistency with delayed confirmation.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Local queuing delays confirmation but prevents data loss [check]
Hint: Booking queues locally on calendar service failure, delaying confirmation [check]
Common Mistakes:
5. If the WebSocket server crashes unexpectedly, what is the immediate failure mode experienced by connected clients?
medium
A. Clients automatically reconnect without losing any messages due to built-in buffering.
B. Clients switch to Long Polling automatically to maintain connection without message loss.
C. Clients receive a connection close event and must reconnect; messages sent during downtime are lost unless application-layer retries exist.
D. Clients continue to send messages which are queued by the network until the server recovers.

Solution

  1. Step 1: Understand WebSocket failure behavior

    When the WebSocket server crashes, the TCP connection closes, and clients receive a close event.

  2. Step 2: Trace message delivery impact

    Messages sent during downtime are lost unless the application implements retries. Clients must reconnect manually or via client logic. There is no automatic buffering or fallback to Long Polling.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    WebSocket crash -> connection close event, no automatic buffering [check]
Hint: WebSocket crash -> clients disconnect, no auto-retry [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard