A Little Technical Information Behind The Playlist — Season 1, Episode 4 (“The Coder”)
A Netflix original series dramatizes the technology behind Spotify. This will just attempt to scratch the surface of it.
The fourth episode of “The Playlist” seemed like a perfect backdrop for a system design interview. Andreas Ehn, played by Joel Lützow, broke the fourth wall to diagram Spotify’s design, complete with a trade-off decision (client-server network vs. peer-to-peer network), an engineer meeting with a solution (hybrid approach), and the invention of some revolutionary network protocol that Spotify subsequently patented. The episode, I learned, is rooted in reality even though it is dramatized.
Who this blog post is for:
- Anyone who watched “The Playlist” on Netflix and is interested in the technology behind it
- Anyone who wants a brief explanation of how Spotify worked in the early days
Who this blog post is not for:
- Someone who actually has an upcoming system design interview and wants to know the full answer to the “design Spotify in 45 minutes” interview question. Here is an Educative blog post answer to “design Spotify,” so that anyone who stumbled here does not waste a click
- Someone who wants a very in-depth answer, though a couple papers will be referenced (here is Spotify’s actual paper)
- Someone who wants to know how Spotify works today, not how it worked several years ago
Motivation: I started a blog series called “baseline system design,” which was meant to be an original twist on the million other Medium articles you will find about system design. It would talk about hypothetical system designs, the way real system design interviews often do, but it would combine “book answers” with information about what software companies actually do.
The series never really found its footing. Seemingly simple questions, like how Facebook generates its newsfeed, suddenly became more complicated. If asked to design the Facebook newsfeed in a real interview, you might pull from Alex Xu’s book at some point in the interview and talk about the tradeoffs between fanout-on-write, fanout-on-load, and a suggested hybrid approach between the two. This, depending on what the interviewer gave you, might be acceptable. But finding out what Facebook actually does proved challenging — this paper states that Facebook uses a model that is primarily pull-based, and this paper was published and peer-reviewed, but it is unclear to me where they got this information. This Facebook blog post is cited as their source, but the exact section I believe they are referencing does not necessarily mean that they use a model that is primarily pull-based, as stated. To make matters more confusing, System Design Primer simply treats Twitter newsfeed and Facebook newsfeed as exactly the same.
How The Episode Goes
*Spoilers*
Andreas Ehn is hired by Spotify CEO Daniel Ek as CTO. Every episode chronicles the rise of Spotify from a different perspective, starting with Daniel’s. Andreas, in contrast, is a brilliant programmer responsible for leading the developers.
Andreas presents the CEO with a Spotify prototype, which more or less looks like modern day Spotify. It is too slow. To the viewer Spotify seems fast enough, but Daniel Ek yells about how bad the speed is.
Due to dwindling funds, Daniel Ek matter-of-factly requests that they switch from client-server to peer-to-peer. Andreas thinks that this will not be easy. Daniel Ek is adamant, and even breaks a laptop at some point for unrelated reasons, to show the viewer how demanding he is. An engineer at a bar suggests they use a hybrid approach, starting with client-server and then switching to peer-to-peer to balance speed and cost. Their achievement is incredible, but Daniel Ek says it is not good enough and nearly makes Andreas quit. Andreas, ready to give up, has a dramatic revelation while watching traffic and realizes that they can accept some data loss. He invents a new protocol, patents it, and Daniel Ek proclaims Spotify is now perfect.
Down The Rabbit Hole…
Someone on Reddit asked the obvious — is that not just UDP? The top answer is that Spotify’s traffic is mostly TCP, but I am not sure where they got this. Their paper seems to suggest that they were only using TCP. From the paper:
While UDP is the most common transport protocol in
streaming applications, Spotify instead uses TCP. Firstly, hav-
ing a reliable transport protocol simplifies protocol design and
implementation. Secondly, TCP is friendly to the network in
that TCP’s congestion control is friendly to itself (and thus
other applications using TCP), and the explicit connection
signaling assists stateful firewalls in better maintaining their
state tables. Thirdly, as streamed material is shared in the peer-
to-peer network, the re-sending of lost packets is useful to the
application.
I am not sure if there is any truth behind the Netflix scene of Andreas staring at traffic, realizing they can accept “lossy streaming,” and then patenting a protocol the next morning that he says will have a place in computer science history. This scene may primarily be for dramatic effect, since it is just minutes after Andreas angrily proclaims that Daniel Ek can make the wheels of a car move faster, or an engine bigger, but cannot possibly change the road. To a viewer, maybe this scene implies that Andreas found a way to even change the metaphorical road.
The second part, Spotify’s “hybrid approach,” is much easier to corroborate.
Though likely out of date, Spotify’s paper states that they used a combination of client-server access and a peer-to-peer protocol. They had eight million tracks, a legal service, and their own proprietary protocol. I am not debating that their protocol is original, I just suspect that its significance was exaggerated.
The player cached tracks they had played. Caches were large (56% were over 5gb) and used LRU (least recently used) for cache eviction. Cached files were served in peer-to-peer overlay.
When you streamed a track, you requested the first piece from Spotify servers. Meanwhile, you searched for peers with the track and when the buffer was sufficient, you switched to peer-to-peer. Towards the end of the track, you would start to pre-fetch the next one.
This next part is from an independent blog post from 2011 that diagrammed facts from the aforementioned paper:
Only 8.8% of music playback comes from Spotify’s servers. The rest comes from the peer-to-peer network (35.8%) or your local cache (55.4%). The exception here is Spotify on smartphones, which gets all the music directly from the Spotify servers.
— Source
You can also view their PowerPoint, which has the same information in more streamlined fashion.
A Summary
- There is a Netflix original series about Spotify. Episode four is about one of their two most important programmers
- One major technological breakthrough in the episode is the realization that they can use a hybrid approach between client-server access and a peer-to-peer network. This breakthrough is rooted in truth (though it should be noted it is outdated)
- The second major technological breakthrough in the episode is the realization that their protocol can be lossy. This part may or may not be true…but seems less true
