Design a short-video feed (ShareChat Moj / Reels)

Instant start is a client-plus-CDN problem, not a server one. First, the feed response already contains the CDN manifest URL, so there is no extra API call when the user swipes. Second, the app keeps a local queue and prefetches the first 1-2 segments of the next 2-3 videos at a modest bitrate (360p or 480p). When the user swipes, playback starts from local storage in tens of milliseconds. Third, the transcoder makes the first segment short (about 1 s) and starts each segment with a keyframe so the player can decode immediately. Fourth, the player starts at a conservative bitrate and steps up with ABR (adaptive bitrate) once it measures bandwidth, which matters on Jio and Airtel 4G in smaller towns. The cost of prefetching is wasted bandwidth when users skip, so limit it: prefetch only the first segment, cancel prefetches the user scrolls past, and use network type (Wi-Fi vs cellular) and data-saver mode. On the CDN side, segments are immutable and cached with long TTLs, so hit rate stays above 95%. Measure time-to-first-frame and rebuffer ratio from the client, broken down by network and region; these are the SLOs that matter, not server latency.

You cannot score 100M videos per request, so the feed uses a funnel. Candidate generation pulls ~1,000-2,000 videos from cheap sources: approximate nearest neighbours of the user's embedding in a vector index (FAISS, ScaNN or Milvus), trending videos for the user's language and region, videos from followed creators, and collaborative signals ('people who finished X also finished Y'). A light model trims this to ~300, then a heavier model scores each candidate using user features, video features and cross features. The objective is a weighted mix of predicted watch time, completion, likes, shares and negative signals like fast skips and 'not interested'. Final re-ranking adds diversity and freshness rules. Latency budget: ~30 ms retrieval, ~60 ms ranking on GPUs or optimised CPUs, ~20 ms feature fetch, well inside 200 ms. Precompute where possible: you can build the next page in the background while the user watches the current one. For a new user with no history, use language picked at signup, location, device and the most popular videos, then learn fast from the first 20 swipes because short videos give very dense feedback.

A new video has no engagement data, so the system cannot rank it well. The standard answer is staged exposure. Every live video first goes to a small test pool, for example 300-500 users who like that topic and language. If completion rate and like rate beat the baseline for its category, it is promoted to a bigger pool (5k, then 50k, then open distribution). If it fails, it stops. This gives every creator a fair chance and caps the damage from low-quality content. Moderation must sit before wide distribution: ML first, and humans before a video crosses a reach threshold, because the cost of a harmful video going viral is much higher than a delay. Viral videos also cause a different technical problem: hot keys. A video getting 50k views per second means its counter and metadata rows become hot. Cache metadata in the feed service and CDN, and aggregate counters in Flink with per-minute flushes instead of incrementing one row per view.

At roughly 25B views a day, egress dominates cost. Levers a senior candidate should mention: serve most views at 480p because phone screens and networks rarely need 1080p; use efficient codecs (H.264 for compatibility, H.265 or AV1 for devices that support hardware decoding, which can cut bytes by 30-50%); keep CDN hit rate high with immutable, versioned URLs; use multiple CDNs with price-based routing plus ISP-embedded caches (Indian ISPs host caches for large players); and limit wasteful prefetching. Transcoding is the second cost: transcode lazily for higher rungs, for example produce 720p and 1080p only once a video passes the first test pool, since most uploads never get many views. Delete raw uploads after a retention window. Storage tiers matter too: move videos with no views in 90 days to cheaper cold storage, and accept a slower first byte if one is ever requested.

Progressive MP4 is simpler and one file per rendition, but it cannot switch bitrate mid-play. HLS (or DASH) with 2 s segments supports adaptive bitrate and fast start, which matters on Indian mobile networks. The cost is more objects and a manifest fetch; we hide the manifest fetch by prefetching. For very short clips some apps use MP4 at a fixed low bitrate, which is a valid choice if you explain it.

A Twitter-style precomputed timeline does not fit: the For You feed is not from people you follow and should react to your last few swipes. We rank at request time but build the next page ahead in the background, getting most of the latency benefit. The Following feed can use fan-out on read from videos_by_author because follow counts per user are modest.

Daily batch features are simple and cheap, but the feed would ignore what you did in the last hour. Streaming features through Kafka and Flink add operational cost, but short-video engagement depends heavily on session intent. A common middle path: daily-trained model weights, real-time session features.

Showing '1.2M views' does not need exact real-time counts. Aggregate in the stream job and flush every few seconds. Creator payouts or ad billing, if added later, would use a separate, deduplicated batch pipeline.

Traffic triples between 9 and 11 pm and swings with events. Feed and ranking services are stateless and autoscale on CPU/GPU utilisation, but GPU capacity is slow to add, so keep headroom and a fallback: if the heavy ranker is overloaded, serve light-ranker results or cached popular-in-region feeds. Users barely notice a slightly worse ranking; they notice errors.

Upload spikes (festivals, trends) create a queue of transcode jobs. Prioritise: creators with many followers and short videos first, produce low rungs first so the video goes live quickly, add higher rungs later. Use spot instances for the worker fleet, since jobs are retryable.

A viral video can get tens of thousands of reads and likes per second. Cache metadata in local in-process caches with short TTLs, and use sharded counters or stream aggregation for likes and views.

The feed service falls back to a precomputed list of top videos per language and region, refreshed every few minutes and stored in Redis. The app keeps playing; personalisation drops for a while. This is a graceful degradation, not an outage.

Use multiple CDNs; the manifest URL host can be switched per region via DNS or by the feed service. Client retries a failed segment on an alternate host.

Jobs are idempotent: output paths are keyed by video_id and rendition, so a retry just overwrites. Kafka consumer commits offset only after completion; failed jobs go to a dead-letter queue after N tries.