How Spotify starts playing music in under a second

The Problem Statement

Interviewer: "You tap a song on Spotify and it starts playing almost immediately, even on a mediocre cellular connection. How does Spotify achieve sub-second playback start times? And what happens behind the scenes when you skip to the next track?"

This question tests three things: your understanding of content delivery and edge caching for media files, your knowledge of client-side prefetching and how the player anticipates what the user will listen to next, and whether you can reason about codec selection, bitrate adaptation, and local cache management on a resource-constrained mobile device.

Most candidates say "they use a CDN" and stop. The strong answer explains the full pipeline: how tracks are encoded at multiple quality tiers, how the client prefetches upcoming songs from the queue, how the local disk cache prevents redundant downloads, and how adaptive bitrate switching keeps playback smooth when the network degrades.

I have seen variants of this question at Spotify (obviously), Amazon Music, and Apple. The underlying architecture applies to any audio streaming platform.

Clarifying the Scenario

You: "Great question. Before I dive in, I want to make sure I scope this properly."

You: "When you say 'plays instantly,' are we focused on the startup latency for the very first byte of audio, or the seamless transition between consecutive tracks?"

Interviewer: "Both. I want to understand why the first tap is fast and why skipping is smooth."

You: "Got it. Should I assume we are talking about the mobile app on a cellular connection, or the desktop client on broadband?"

Interviewer: "Mobile, since that is the harder case."

You: "And one more thing. Should I focus on just-in-time streaming, or also cover offline mode and encrypted cache?"

Interviewer: "Cover offline briefly, but focus on the streaming path."

You: "OK. I will structure my answer in four parts: how Spotify encodes and distributes audio files at multiple quality levels, how the CDN edge layer gets the first bytes to the client quickly, how predictive prefetching downloads the next track before you need it, and how the local disk cache avoids re-downloading songs you have already heard."

Scoping like this takes 30 seconds and completely changes how the interviewer perceives you. They hear structure, they hear confidence, and they know you will not ramble.

My Approach

I break this into five parts:

1. Audio encoding pipeline: Spotify encodes every track into multiple codec/bitrate combinations. Ogg Vorbis at 96, 160, and 320 kbps for most platforms, AAC for iOS and web, and Opus for newer clients. Each bitrate tier is a separate file on the backend.
2. CDN edge delivery: Audio segments are distributed to CDN edge nodes (Spotify uses Google Cloud CDN and their own edge infrastructure). The first segment of a song is small (a few hundred KB) and can be served from an edge PoP within 50-100ms for most users.
3. Predictive prefetching: While the current song plays, the client downloads the beginning of the next song in the queue. It does not wait for you to press skip. By the time you finish a song, the next one is already partially (or fully) on your device.
4. Local disk cache: Spotify maintains a cache on the device (typically 1-10 GB, depending on settings). Recently played tracks and prefetched content live here. An LRU eviction policy reclaims space when the cache fills up.
5. Adaptive bitrate switching: On mobile, the client monitors network conditions. If bandwidth drops, it falls back from 320 kbps to 160 or 96 kbps mid-stream, rather than buffering.

The reason playback feels instant is that all five of these systems work together. The CDN makes the first request fast. Prefetching eliminates the request entirely for the next song. The cache eliminates the request for songs you have heard before. And adaptive bitrate prevents stalls when the network gets worse.

Here is the latency contribution of each layer:

The target: the first byte of audio should reach the decoder within 200ms of the user tapping play. For prefetched tracks, the target is 0ms (instant). Let me walk through the architecture that achieves this.

Before we look at the diagram, here is the key mental model: audio streaming is a pipeline with three stages, and each stage is designed to be as fast as possible.

Stage 1: Encoding (happens once, offline). Every song is processed through an encoding farm that produces multiple quality variants. A 4-minute song might generate 15+ output files (3 codecs times 3-5 quality tiers). This is a batch process that runs when new tracks are ingested. The encoding decisions (which codecs, which bitrates, how to segment) directly impact how fast the client can start playback.

Stage 2: Distribution (happens continuously, background). Encoded segments are pushed to CDN edge nodes worldwide. Popular content is proactively replicated. Long-tail content is pulled on demand (origin pull). The distribution layer determines the minimum network latency for a cache miss.

Stage 3: Client playback (happens in real time). The client orchestrates cache lookups, network requests, prefetching, decoding, and audio output. Every millisecond matters here because the user is waiting. The client's job is to make network latency invisible through caching and prediction.

Now let me show you the full architecture.

The Architecture

Here is how a song plays from tap to audio:

1. You tap a song. The client checks the local disk cache first. If the first segment is cached, playback starts immediately from disk with zero network latency.
2. If not cached, the client resolves the nearest CDN edge PoP through DNS. Because Spotify pre-resolves DNS for audio endpoints, this adds almost no delay.
3. The client requests just the first few segments (enough for 2-3 seconds of audio). At 160 kbps, that is roughly 40 KB per second, so the first second of audio is only ~20 KB. On any reasonable connection, this arrives in under 200ms.
4. The decoder starts playing as soon as the first segment arrives. It does not wait for the entire file. This is progressive playback, the same principle as video streaming but simpler because audio files are much smaller.
5. While the current song plays, the prefetch engine quietly downloads the first 10-30 seconds of the next track in the queue. By the time the current song ends, the transition is seamless.

The key insight: Spotify does not wait for you to take action. By the time you want the next song, the client already has it.

Here is the codec selection logic per platform:

The codec choice is made at connection time, not per-request. The client announces its supported codecs during authentication, and the backend returns audio URLs pointing to the correct codec variant. This avoids any runtime codec negotiation overhead.

Here is a quick back-of-envelope calculation for data consumption:

At Very High quality, an hour of listening uses 144 MB. This is relevant for understanding why prefetching decisions matter: aggressively prefetching at 320 kbps burns through mobile data 13x faster than streaming at 24 kbps. The prefetch engine must be bandwidth-aware.

Predictive Prefetch and Next-Track Buffering

The single biggest reason Spotify feels instant is that it starts downloading the next song before you need it. This is not a simple "download the next file in the queue." The prefetch engine is surprisingly sophisticated.

Think of it like a waiter at a restaurant who starts preparing your dessert before you finish your main course. If they guess right (which they do 85% of the time), the dessert appears the instant you push your plate away. If they guess wrong, there is a slight wait while they prepare something else. The cost of a wrong guess is one wasted dessert prep, not a catastrophe.

Let me walk through the three scenarios shown in this diagram:

Scenario 1: Normal transition (Song A to Song B). While Song A plays, the prefetch engine downloads Song B in the background. When Song A reaches its last 5 seconds, the player starts blending the audio: Song A fades out while Song B fades in. The user hears a seamless crossfade with zero gap. This is the happy path and covers roughly 70-80% of all transitions.

Scenario 2: Skip (Song A to Song C). The user presses skip mid-song. Song C was not prefetched (the engine had only prefetched Song B). The client immediately requests Song C from the CDN. Even without prefetch, the first segment arrives in under 200ms because of CDN edge proximity. There might be a barely perceptible gap. Meanwhile, the prefetch engine cancels the Song B download (wasted bandwidth, but minimal) and starts prefetching Song D.

Scenario 3: Cache hit (not shown, but the fastest case). Song A was already in the local disk cache from a previous listen. The client reads it directly from SSD. Playback starts in under 50ms, limited only by the time to read from disk and decode the first segment. This is the ideal path for repeated listening.

The prefetch engine uses several signals to decide what and when to download:

• Queue position: The next 1-2 songs in the explicit queue are always prefetched. This is the simplest case.
• Autoplay predictions: When the queue is empty, Spotify's recommendation engine provides the next 5-10 predicted tracks. The client prefetches the top 1-2.
• Playback progress: Prefetching starts after the user has listened to about 5 seconds of the current track. This avoids wasting bandwidth when someone is quickly skipping through songs.
• Network conditions: On WiFi, the client prefetches more aggressively (full tracks, higher quality). On cellular, it prefetches only the first 30 seconds at a lower bitrate.

For your interview: the phrase "adaptive prefetch based on engagement signals" is what separates a good answer from a generic one. It shows you understand the bandwidth-latency tradeoff rather than just the concept.

Here is a summary of prefetch behavior by network type:

So when does this actually matter in an interview? Prefetching is the answer to "why does skipping to the next song feel instant?" If you only talk about CDN latency, you have missed the point. The CDN matters for the first-ever play of a song. For every subsequent interaction (next track, replay, shuffle within a familiar playlist), the prefetch engine and local cache are doing all the heavy lifting.

The rule of thumb: on a healthy connection, the user should never wait for network I/O when transitioning between tracks. The only acceptable wait time is the 200ms first-byte latency for a cache miss on a song they have never heard before.

Local Cache Management Strategy

The local disk cache is the unsung hero of perceived performance. If a song is already on disk, playback starts with zero network latency. The cache management strategy determines what stays and what gets evicted.

The cache lives on the device's internal storage (or SD card on Android if configured). It is not an in-memory cache. It persists across app restarts, device reboots, and even app updates (the cache directory is preserved). This means a user who listens to the same commute playlist every day only downloads those tracks once, regardless of how many times they restart the app.

The cache also stores metadata alongside the audio data: track ID, codec, bitrate, encryption key reference, download timestamp, play count, and checksum. This metadata is stored in a lightweight SQLite database that the cache manager queries when deciding what to evict. The audio data itself is stored as individual encrypted files in a flat directory structure, named by content hash.

Spotify's cache has several layers of priority:

The cache is encrypted with a device-specific key. This is not just DRM theater. It prevents someone from copying the cached Ogg/AAC files to another device and playing them outside the app. The encryption also means that if the user's subscription expires, the cached files become unplayable without re-authentication.

Here is a rough sizing exercise for the cache. These numbers help you ground the discussion in concrete details during an interview:

Notice that playlist repeaters barely grow the cache after the first session. This is why the repeat-detection heuristic matters: it identifies tracks that should never be evicted, freeing cache space for genuinely new listens.

Adaptive Bitrate Selection Under Network Changes

Unlike video (where you switch between visible quality levels), audio bitrate switching is nearly invisible to the listener. Moving from 320 kbps to 160 kbps Ogg Vorbis is noticeable only to trained ears on good headphones. This gives the audio client more leeway than a video player.

The asymmetry is important. When Netflix drops from 4K to 720p, the user sees it immediately and might complain. When Spotify drops from 320 kbps to 160 kbps, most users do not notice at all. This means the audio player can be more aggressive about downgrading quality to prevent stalls, because the perceived cost of downgrading is much lower than the perceived cost of buffering.

Here is the hierarchy of priorities for the audio player (in order):

1. Never stall playback (most important). Any audible gap or spinner is a failure.
2. Maintain current quality if the buffer is healthy.
3. Upgrade quality when extra bandwidth is consistently available.
4. Minimize unnecessary switches (quality ping-pong is jarring even if individual switches are not).

This priority ordering drives the state machine design.

The bitrate selector runs as a state machine with hysteresis. The upgrade threshold is higher than the downgrade threshold to prevent oscillation. If you downgrade at 400 kbps, you do not upgrade again until 600 kbps. This 200 kbps gap prevents the "quality ping-pong" effect where the audio keeps switching back and forth.

The client also maintains a playback buffer of roughly 10-30 seconds of decoded audio. As long as this buffer is healthy (above 5 seconds), the player can tolerate brief bandwidth dips without doing anything. The buffer acts as a shock absorber.

The buffer works differently from a video player's buffer. Video buffers store compressed data (H.264/H.265 NAL units). Audio buffers typically store decoded PCM samples because audio is cheap to decode and the decoded data is small. A 30-second buffer of 44.1 kHz stereo 16-bit PCM is about 5.3 MB. This fits easily in memory on any modern device.

Why decode early? Because the critical path for audio playback is the time between "user taps play" and "sound comes out of the speaker." Decoding ahead of time means the audio output callback can pull PCM directly from the buffer without waiting for a decode step. This shaves 5-20ms of latency on every buffer refill.

Here is a breakdown of how the buffer interacts with the bitrate selector:

The goal is to never reach the bottom two rows. If the system is working correctly, the buffer stays above 5 seconds almost all the time, and stalls are extremely rare (Spotify targets < 0.1% of sessions experiencing any buffering).

The Tricky Parts

1. Gapless playback between tracks: Two songs on the same album should transition without a gap or click. The encoder strips silence from the end of each track and stores the exact sample offset. The client's crossfade engine uses this metadata to overlap the last few milliseconds of one track with the first few of the next. Getting this wrong (or ignoring it) produces audible gaps that frustrate audiophiles.

2. Skip storms: Some users rapidly skip through 10-20 songs looking for the right one. Each skip triggers a prefetch cancellation (for the old next track) and a new urgent fetch (for the just-selected track) plus a new background prefetch (for the new next track). Without careful request cancellation, you accumulate zombie downloads that waste bandwidth and compete with the track the user actually wants to hear.

3. Offline-to-online transitions: A user boards a subway (loses signal) and the app falls back to cached content. When they emerge, the app needs to seamlessly resume streaming without a gap. This requires the client to track exactly where the cached content ends and where to resume from the CDN. The segment boundaries must align perfectly.

4. Cache corruption: Disk writes can fail silently (power loss, storage full). If a cached segment is corrupted, the decoder produces noise or crashes. Spotify checksums every cached segment and silently re-downloads corrupted ones. The user never knows it happened, but the cache layer must validate integrity on every read.

5. DRM and key rotation: Cached files are encrypted. The decryption key is tied to the user's active session. If the key rotates (login elsewhere, subscription change), cached files must be re-encrypted or invalidated. Doing this lazily (at read time) avoids blocking the UI, but it adds complexity to every cache read path.

6. Free tier ad insertion: Spotify Free users hear ads between songs. The ad audio must be fetched, decoded, and inserted into the playback stream without a jarring gap. The ad insertion engine runs as a separate prefetch pipeline that downloads ad audio during the current song and splices it into the crossfade buffer. If the ad fetch fails (network issue), the client skips the ad rather than blocking playback. This is architecturally distinct from the music prefetch pipeline but shares the same cache and decoder infrastructure.

7. Seek within a song: When a user drags the seek bar to a different position, the client needs to find the correct segment for that timestamp. If the segment is cached, seek is instant. If not, the client calculates the byte offset from the segment map (stored in the track's metadata) and requests just that segment from the CDN. Accurate seeking requires the segment map to include precise timestamp-to-byte-offset mappings, which the encoding pipeline generates during segmentation.

8. Multi-device playback (Spotify Connect): A user starts a song on their phone, then transfers playback to their smart speaker via Spotify Connect. The smart speaker must resume from the exact position. The phone sends the current playback position (timestamp + buffer state) to the Spotify backend, which relays it to the speaker. The speaker then fetches audio from its nearest CDN edge starting at that offset. If the speaker has its own cache and the song happens to be there, it plays from cache. Otherwise it fetches from CDN. The critical detail is that the seek position must account for the crossfade buffer: if the phone is 5 seconds into a crossfade, the speaker needs to start 5 seconds earlier to match the audio state.

9. Codec fallback on decode errors: If the Vorbis decoder encounters a corrupted segment or an unsupported feature, it should not crash the app or play garbled audio. The client catches decode errors and falls back to the next available segment, interpolating a brief silence (10-50ms) to mask the gap. If errors are persistent for a track, the client can re-request the segments at a lower bitrate (which uses simpler encoding parameters and is less likely to trigger edge-case decoder bugs).

What Most People Get Wrong

How I Would Communicate This in an Interview

Here is how I would actually say this:

"Spotify achieves sub-second playback through three layers working together.

First, every track is encoded at multiple bitrates, typically 96, 160, and 320 kbps in Ogg Vorbis for Android and AAC for iOS. These are stored on CDN edge nodes close to the user.

Second, the client maintains a local disk cache of 1 to 10 GB. Before making any network request, it checks the cache. For frequently played songs and prefetched tracks, the cache hit rate is quite high, probably 40 to 60 percent. A cache hit means zero network latency.

Third, and this is the most interesting part, the client predictively prefetches the next track in the queue while the current song is still playing. It starts downloading after the user has listened for about 5 seconds, which confirms they are actually listening and not just skipping through. By the time the current song ends, the next one is already on disk.

For network degradation, the client runs a simple state machine that monitors bandwidth and buffer level. It will downgrade from 320 to 160 kbps mid-stream at segment boundaries, with a tiny crossfade to make the switch inaudible. It uses hysteresis to avoid oscillating between quality levels.

The failure mode to watch for is skip storms, where a user rapidly skips through many songs. The client needs aggressive request cancellation to avoid piling up zombie downloads that compete with the track the user actually wants."

Interview Cheat Sheet

• "How does Spotify start so fast?" → Three layers: local disk cache (zero latency), CDN edge (< 100ms), and predictive prefetch (next track pre-downloaded).
• "What codecs does Spotify use?" → Ogg Vorbis for Android/desktop, AAC for iOS/web, Opus for newer clients. Three quality tiers: 96, 160, 320 kbps.
• "How does prefetching work?" → Client starts downloading next track after user listens for 5+ seconds. Prefetches first 10s immediately, rest after 50% completion.
• "What about bandwidth adaptation?" → State machine with hysteresis. Downgrade at 400 kbps, upgrade at 600 kbps. Switch at segment boundaries with crossfade.
• "How big is the cache?" → 1-10 GB, user-configurable. Weighted LRU eviction with priority tiers: pinned > recently played > prefetched > autoplay.
• "What about encryption?" → Cached files encrypted with device-bound key. Requires active session for decryption. Prevents piracy from cache extraction.
• "How does gapless playback work?" → Encoder stores exact sample offsets. Client crossfade engine overlaps last/first samples between consecutive tracks. No silence gap.
• "What if the user skips rapidly?" → Client enters "skip mode" with aggressive request cancellation. Prefetch only 2-3 seconds per track. Wait for user to settle before full download.
• "How does offline mode differ?" → Same encrypted cache, but entire tracks are pre-downloaded at user's chosen quality. Playback is purely local with zero network.
• "What is the failure mode?" → Skip storms (zombie downloads), cache corruption (checksummed segments), and offline-to-online transitions (segment boundary alignment).

Test Your Understanding

---

---

---

---

---

---

---

Quick Recap

1. Spotify encodes every track in multiple codecs (Vorbis, AAC, Opus) at three quality tiers (96, 160, 320 kbps) to match platform and network conditions.
2. CDN edge PoPs place audio segments within 50-100ms of most users, but the local disk cache eliminates the network entirely for frequently played and prefetched tracks.
3. The prefetch engine downloads the next song in the queue while the current one plays, starting after 5 seconds of confirmed listening to avoid wasting bandwidth on skipped tracks.
4. The local disk cache uses weighted LRU eviction with priority tiers: pinned offline tracks are never evicted, and frequently played songs have higher retention than autoplay tracks.
5. Adaptive bitrate switching happens mid-stream at segment boundaries with a crossfade, using a hysteresis state machine (downgrade at 400 kbps, upgrade at 600 kbps) to prevent quality oscillation.
6. Gapless playback relies on encoder metadata (padding offsets) and client-side crossfade with configurable duration (0-12 seconds).
7. All cached files are encrypted with a device-bound key to prevent piracy, and checksummed to detect corruption.
8. Skip storms are handled by aggressive request cancellation and a reduced prefetch mode that downloads only 2-3 seconds per track until the user settles.

Related Concepts

• How Netflix prevents buffering on slow networks: The video equivalent of this problem. Netflix faces the same adaptive bitrate challenge but at 15x the data rate, making the tradeoffs more extreme.
• How CDN cache invalidation works: Deep dive into how CDN edge nodes decide what to cache and when to evict, directly relevant to Spotify's audio segment caching.
• How video streaming works: Covers HLS/DASH adaptive streaming protocols that share architectural DNA with audio streaming but with different constraints.
• How the hot key problem happens: Relevant when a viral song creates a thundering herd on specific CDN edge nodes, a real problem Spotify faces during major album drops.
• How push notifications work: The notification that triggers "New album from your favorite artist!" which then triggers millions of simultaneous play requests, connecting the CDN pre-warming strategy to the notification pipeline.