Short video feed system design interview: a vertical video feed, from the hiring side

Candidates who spend fifteen minutes on the ranking service have answered a backend question. Name the feed API in one sentence: pages of item ids with a cursor, each item carrying a stream URL, a poster image and its duration. Then move to the device.

The first ten minutes earn the most points when you turn "smooth" into numbers you can test. Name them per device tier, at a percentile, never as an average from your own phone.

The last row is the one strong candidates add unprompted. A feed that prefetches aggressively looks instant in a demo, and in the field it spends a user's data plan on videos they swiped past in half a second. Wasted prefetch is a budget too, and someone has to own it.

The structural move interviewers wait for is separating three levels of readiness. They cost very different amounts, so they get different window sizes.

• Playing: the visible item, decoding, with audio.
• Prepared: the next item, and the previous one for a swipe back, loaded into a player with the first frame decoded and paused. This is what makes a swipe feel instant. It holds a decoder and buffers, so the count is small.
• Prefetched: the next few items as bytes only, the first seconds of each written to the disk cache. No decoder, no surface. Cheap in memory, not free in data.

Prefetch only the start of each video. Most swipes happen in the first seconds, so downloading the full file of an item three positions ahead buys almost nothing and spends the most. When the user settles on an item, its buffer grows; when they swipe fast, cancel the prefetches that fell behind, so the network serves the item on screen first.

Then say how the window changes. On Wi-Fi with a charged phone it can run a few items ahead. On cellular, in low power mode, under memory pressure or when the device is hot, it shrinks, down to preparing only the next item. The window is a policy with inputs, not a constant in the view controller.

A candidate who creates one player per cell in a list has not shipped video. Hardware decoders are limited per device, each player holds buffers and a rendering surface, and creating players is slow. The answer is a small pool, reused as the user scrolls.

@MainActor
final class PlayerPool {
    private var idle: [AVPlayer] = []
    private var inUse: [Int: AVPlayer] = [:]   // feed index -> player

    init(capacity: Int = 3) {
        idle = (0..<capacity).map { _ in AVPlayer() }
    }

    func attach(_ url: URL, at index: Int, current: Int) {
        if inUse[index] != nil { return }
        if idle.isEmpty, let far = inUse.keys.max(by: { abs($0 - current) < abs($1 - current) }) {
            release(far)                       // recycle the item furthest from the screen
        }
        guard let player = idle.popLast() else { return }
        let item = AVPlayerItem(url: url)
        item.preferredForwardBufferDuration = index == current ? 0 : 2   // neighbours buffer a little
        player.replaceCurrentItem(with: item)
        inUse[index] = player
    }

    func release(_ index: Int) {
        guard let player = inUse.removeValue(forKey: index) else { return }
        player.pause()
        player.replaceCurrentItem(with: nil)
        idle.append(player)
    }
}

Two details to say out loud. A preferredForwardBufferDuration of zero means the system chooses, which is right for the item on screen; a short explicit value keeps neighbours from filling memory with video nobody is watching yet. And the pool size is the prepared window plus one, decided by the device tier, so a low-end phone may run two players where a flagship runs three.

The invariant worth stating: no more players exist than the pool allows, whatever the scroll speed. A fling through forty items must recycle, never allocate.

Video needs its own disk cache, sized in bytes, separate from the image cache for posters and avatars. Mixing them lets one long video push out every thumbnail on screen.

Eviction order is the decision. Least recently used is the default and it is close, but a feed knows more than recency: evict watched before unwatched, and the far past before the near future. An item the user finished is unlikely to be needed again; a prefetched item two positions ahead is about to be. Give the cache a ceiling per item and a total ceiling, and make the total smaller on devices that report low free storage, because the user and the OS can both delete your files.

One more rule: a cached segment is keyed by the exact rendition, not just the video id. Otherwise a quality change mid-session can mix renditions in one playback, or a reused cache entry plays a resolution the current policy would never choose.

Serve adaptive streams, HLS on iOS and HLS or DASH on Android, with a ladder of renditions. The player's adaptive logic picks a rendition as playback goes. Your design decides the start and the caps.

Start low. The first frame matters more than the first second's sharpness, and a short video may be over before a high starting bitrate would have paid off. Use the measured throughput from recent segments, not the network type label: a strong cellular link can beat a congested Wi-Fi. Cap the peak on cellular when the user chose data saving, and cap it by screen size, since a small phone gains nothing from the top rendition. On iOS that cap is preferredPeakBitRate on the player item; on Android it is a track selection constraint on the player.

Then name the coupling. A higher bitrate costs more decoding work and more radio time, which costs heat and battery. Bitrate policy and thermal policy are one system, and treating them separately is how the phone overheats while every metric for video quality looks excellent.

Watch events are not decoration in this product. They feed ranking, so a lost or reordered event degrades every future page. The round tests whether you treat them as data with a contract.

• Persist before sending. Write each event to a local queue first, then upload in batches. The process will be killed mid-scroll, and an in-memory buffer loses exactly the last minute of a session, which is the minute ranking most wants.
• Give each event an id and a sequence number per session. The server deduplicates by id, so retries are safe, and orders by sequence, not by device clock or arrival time. Batches can arrive out of order after a reconnect.
• Measure watch time from playback, not from the screen. Count only the time the player was rendering frames, minus stalls. A paused video on screen is not a watched video.
• Send impressions with the cursor of the page they came from, so ranking can tell which page produced which behaviour.

Upload on a timer and on backgrounding, in small batches, and let the OS scheduler handle uploads that wait for a network. Analytics must never compete with the video on screen for bandwidth.

A strong answer does not pretend a streaming feed works offline. It says what offline means for this product. When the connection drops, the user can keep watching what is already cached in the window, then sees a clear state, not an endless spinner. Likes and follows made offline go into an outbox and sync later, idempotently, the same discipline as the offline sync answer.

If the product adds downloads for later, that is a different feature with a different contract: a download state machine, a storage budget and licences that must survive an app update. Name it as a separate scope, so the interviewer knows you see the size of it.

Memory is the first wall. Every prepared player holds decoded frames and buffers, posters sit in an image cache, and the feed keeps growing as the user scrolls. Respond to the platform's warnings before the OS acts: on iOS the memory warning, on Android onTrimMemory. Shrink in a fixed order: drop the prepared previous item, then prefetched bytes held in memory, then the image cache. Trim the feed model itself, keeping ids and cursors for items far behind and dropping their heavy metadata.

Heat is the second wall, and the one candidates miss. A feed is a long session of decoding, network and screen at full brightness. Read the system's thermal signal and step down on a ladder:

enum Tier { case full, reduced, minimal }

func tier(for state: ProcessInfo.ThermalState, lowPower: Bool) -> Tier {
    switch state {
    case .nominal, .fair: return lowPower ? .reduced : .full
    case .serious: return .reduced
    case .critical: return .minimal
    @unknown default: return .reduced
    }
}

Each tier is a set of choices: the window size, the peak bitrate, the pool size. Respond fast when the signal rises and recover slowly, or quality jumps up and down every time the phone warms. And record every step down as an event, segmented by device tier. If the client lowers quality and nobody can see it, a whole cohort of older phones can watch at the floor for weeks with every dashboard green.

The Android row that matters most is the last one. Decoder limits and thermal behaviour vary by chip and by vendor, so the pool size and window are chosen per device tier, and the tier list is data from the field, not a guess from the office drawer of test phones.

Name the numbers: time to first frame after a swipe at p50 and p95, stalls per minute, the share of prefetched bytes never played, peak memory in a ten-minute session, the share of sessions reaching a serious thermal state, and the share of time spent at each quality tier. Segment every one by device tier and OS version, because the average is set by the newest phones.

Change the window size, pool size and bitrate caps behind remote configuration, by device tier, so a bad value can be turned back without an app release. Roll a new player stack to a small share first and compare the five numbers above against the old one before widening it.

The staff column is not more components. It is the same design with budgets, owners and a way to know when it is wrong on a phone nobody in the team carries.

• "The user swipes through twenty videos in five seconds." Tests cancellation and the pool invariant.
• "It is a three-year-old Android phone." Tests budgets per device tier and decoder limits.
• "The user is on a metered plan." Tests the window as a policy and wasted prefetch.
• "After ten minutes the phone is hot." Tests the thermal ladder and its telemetry.
• "The app is killed mid-scroll." Tests the persisted event queue.
• "The train goes into a tunnel." Tests the offline story and the outbox.

Prepare one sentence for each. If you want more prompts in this shape to rehearse, the mobile system design prompt pack is a free set. If a follow-up makes you add a box, your design was missing a decision. If it makes you point at a box that already handles it, you are having the conversation the round is for.

How do you answer "design a short video feed" in a mobile system design interview?

Set budgets first: time to first frame, a stall rate, memory and heat on a low-end device. Then design the window around the visible item: which neighbours are prefetched as bytes, which are prepared in a player, and how many players exist at all. Add a disk cache with an eviction order, a bitrate policy that starts low, analytics that survive the process being killed, and say what changes on iOS and Android.

How many videos should the app preload?

Fewer than candidates expect. Prepare the next item in a decoder-backed player, prefetch the first seconds of the next few as bytes, and keep the previous item warm for a swipe back. The number is a budget per device tier, not a constant, and it shrinks under memory pressure, thermal pressure and cellular data limits.

Should the interview answer go deep on the ranking algorithm?

No. Say the server ranks and returns pages with a cursor, and that the client reports what was watched. The mobile round is about what the device does with the page: playback start, memory, heat, data use and the events that feed ranking back.

How should I practise this round?

Answer out loud against a 45-minute timer, then change one fact: the phone is three years old, the user is on a metered plan, or the app is killed mid-scroll. Answer again. The second pass shows which numbers in your design were decisions and which were guesses.