Spotify Engineering
engineering.atspotify.com · Company blog · on HN since 2020
Spotify Engineering is the company's engineering blog, covering topics from shuffle algorithms and DNS to search libraries and coding agents.
What HN saysCommenters point to it for specific posts, especially the 2014 shuffle article, plus its DNS and cloud infrastructure write-ups.
118HN people shared it
41linked it in comments
112stories submitted
828story points
3 months agolast shared
2020people per year2026
Most-shared posts
- 1How to Shuffle Songs? (2014)12 people · 1 points · first shared 2022 · discussion on HN
- 2Building the Future of Our Desktop Apps7 people · 13 points · first shared 2021 · 3 comments on HN
- 3Creative usernames and Spotify account hijacking6 people · 11 points · first shared 2022 · 1 comments on HN
- 4We Automated Content Marketing to Acquire Users at Scale4 people · 8 points · first shared 2023 · 1 comments on HN
- 5Voyager: Spotify's New Nearest-Neighbor Search Library4 people · 3 points · first shared 2023 · discussion on HN
- 6Basic Pitch: ML model to turn audio into MIDI3 people · 17 points · first shared 2022 · 1 comments on HN
- 71,500 PRs Later: Spotify's Journey with Our Background Coding Agent (Part 1)3 people · 7 points · first shared 2025 · 2 comments on HN
- 8The What, Why, and How of Mastering App Size3 people · 5 points · first shared 2023 · discussion on HN
- 9Coming Soon: Confidence – An Experimentation Platform from Spotify3 people · 5 points · first shared 2023 · discussion on HN
- 10Load Testing for 2022 Spotify Wrapped3 people · 3 points · first shared 2023 · discussion on HN
- 11How to Shuffle Songs? (2014)3 people · 2 points · first shared 2020 · discussion on HN
- 12Spotify Optimized the Largest Dataflow Job Ever for Wrapped 20202 people · 197 points · first shared 2021 · 125 comments on HN
- 13From development to real users: How to create a web performance story2 people · 22 points · first shared 2022 · discussion on HN
- 14Spotify Introducing Natural Language Search2 people · 11 points · first shared 2022 · 1 comments on HN
- 15How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem2 people · 6 points · first shared 2020 · discussion on HN
What HN people wrote when they linked it
avianlyric · 2023-12-28
There’s a really good article from Spotify Engineering that looks at exactly how Spotify bridged this gap between “random” and the “random” people actually expect.
https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
It a good read on understanding what people generally expect when they ask for a random stream of songs (or comics), and how you can meet that expectation by carefully engineering how you generate “random” lists.
bkor · 2023-11-26
Spotify uses (used?) DNS TXT records as well. See e.g. the following article: https://engineering.atspotify.com/2017/03/spotifys-love-hate-relations…
I thought they also used it in their client but cannot find a article about that.
gbrindisi · 2020-11-05
Regarding inventorization of assets: my team also did the same at Spotify last year for Google Cloud Platform.
https://engineering.atspotify.com/2019/06/04/painting-a-picture-of-you…
At the time Cartography support for GCP was lacking, so we just ingested Cloud Asset Inventory data in neo4j.
If you are on GCP I highly suggest using CAI as a backbone for IAM security controls: hands down the best service on the platform for security teams.
jkb79 · 2023-04-13
Disclaimer, I'm a developer working on the Vespa.ai project. One reason is that we simply don't have DevRel teams or marketing teams, but we still have decent interest, from large companies like Spotify using Vespa in production for semantic search (at scale) https://engineering.atspotify.com/2022/03/introducing-natural-language…
On topic: IMHO a better title of the blog post would be:
Do you actually need to enable approximate vector search?
Which is an excellent question, because, introducing approximation also introduces accuracy degradation, plus that you need an ANN algorithm, which also has tradeoffs.
In Vespa, you can choose between exact and approximate, with related tradeoffs such as recall (accuracy), search speed, indexing throughput and resource footprint. Just start easy with exact search, then it's just change the schema definition of the tensor field to include `index` and Vespa will build the necessary data structures for enabling approximation.
onion2k · 2025-12-23
Spotify and Tailscale do...
https://engineering.atspotify.com/feed
https://tailscale.com/blog/index.xml
pella · 2025-12-23
> especially from tech company blogs,
https://engineering.fb.com/
https://netflixtechblog.com/
https://stripe.com/blog/engineering
https://eng.uber.com
https://engineering.linkedin.com/
https://engineering.atspotify.com/
https://tailscale.com/blog
https://careersatdoordash.com/engineering-blog/
https://dropbox.tech/
--
Aggregators:( https://engineering.fyi/ ; https://diff.blog/ )
+ https://hn.algolia.com/?query=engineering%20blog
---
create a public engineering-blog SKILL.md.
( ~ collect the writing patterns that work on HN )
esafak · 2025-06-22
If you like reading blogs, I suggest Spotify's: https://engineering.atspotify.com/2023/03/choosing-sequential-testing-…
mattrighetti · 2024-12-13
Another super interesting article that talks about DNS and how it’s used at Spotify [0] (or was used in 2013)
[0]: https://engineering.atspotify.com/2013/02/in-praise-of-boring-technolo…
yen223 · 2024-11-28
At my last company I helped build the experimentations platform that processes millions of requests per day. I have some thoughts:
- The most useful resource we've found was from Spotify, of all places: https://engineering.atspotify.com/category/data-science/
- For hashing, md5 hash on (user-id + a/b-test-id) is sufficient. In practice we had no issues with split bias. You should not get too clever with hashing. You'll want to stick to something reliable and widely supported to make any post-experiment analysis easier. You definitely want to log the user-id to version mapping somewhere.
- As for in-house vs external, I would probably go in-house, though that depends on the system you're A/B testing. In practice the amount of work needed to integrate a third-party tool was roughly the same as building the platform, but building the platform meant we could test more bespoke features.
wood_spirit · 2024-11-03
And nowadays Spotify uses voyager https://engineering.atspotify.com/2023/10/introducing-voyager-spotifys…
andersco · 2024-09-24
Clickable links:
Spotify blog post: https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
"True" shuffle Live Idea: https://community.spotify.com/t5/Live-Ideas/All-Platforms-Option-to-ha…
ornornor · 2024-05-24
> 50 engineers
50?? Try 1600+ (from https://engineering.atspotify.com/opensource/)
furstenheim · 2024-04-08
Take a look at hexagon pattern from Spotify. Once you start testing the user contract of your services against real databases (testcontainners is a good option), then you can change all the internals and be sure that the externals will work.
https://engineering.atspotify.com/2018/01/testing-of-microservices/
TonyTrapp · 2024-01-23
Mathematical randomness is not exactly a skill required for survival. In fact, our ability to produce random numbers is so bad that our brains consider true randomness to not be random, as this blog post from Spotify shows: https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
mkobit · 2024-01-20
They wrote an interesting blog some time back about how "random shuffle" isn't necessarily what people want, and how their algorithm works (https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/ ). That was a decade ago, so maybe their approach has changed or that it does not perform well under certain conditions (like the one you mention). It works well for me on most playlists on the order of 10s.
_aaed · 2024-01-07
Reminds me of the Spotify shuffle algorithm blog post:
https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
jalada · 2023-12-28
Reminds me of Spotify's post about shuffling songs: https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
bogomipz · 2023-12-04
>"Spotify was a stand-out, almost no large tech company bought into cloud like they did, and everyone said the same thing: "It's not our core competence, it would require more people".
I'm not sure what you mean by this as Spotify was actually quite late buying into cloud. They ran on bare metal through at least 2015. From their engineering blog:
">Thus, in early 2015 we started exploring what a cloud strategy would look like for Spotify."[1]
So they would have been running on bare metal through some of the biggest spikes in growth i.e launching in the US market. I don't think they bought in any more or any less than anyone else who transitioned from bare metal to cloud for the same reasons.
[1] https://engineering.atspotify.com/2019/12/views-from-the-cloud-a-histo…
daturkel · 2023-10-30
Annoy came out of Spotify, and they just announced their successor library Voyager [1] last week [2].
[1]: https://github.com/spotify/voyager
[2]: https://engineering.atspotify.com/2023/10/introducing-voyager-spotifys…
cnity · 2023-08-31
Spotify once had a very similar issue which actually allowed hijacking of other accounts.
https://engineering.atspotify.com/2013/06/creative-usernames/
SethMLarson · 2023-01-04
This is part of what Spotify did to determine urllib3 as an award recipient: https://engineering.atspotify.com/2022/04/announcing-the-spotify-foss-…
r721 · 2022-12-21
Here is related Spotify Engineering blog post from 2014:
>How to shuffle songs?
https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
joek1301 · 2022-06-04
Spotify shuffle is indeed not (uniformly) random, as confirmed by this blog post[1]. The post is eight years old, so it is highly possible the algorithm has changed.
[1]: https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
delusional · 2022-05-01
Spotify had a blogpost about it back in the day[1]. It was based on prior work that's a bit more general[2]. The basic idea was that you don't really want to randomize, you want to distribute.
[1]: https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/
[2]: http://keyj.emphy.de/balanced-shuffle/
seanp2k2 · 2022-01-12
Spotify Desktop is kinda different from the website because of how it uses APIs locally to control things https://engineering.atspotify.com/2021/04/07/building-the-future-of-ou…
VSCode is also appreciably different both in capability and implementation, https://franz-ajit.medium.com/understanding-visual-studio-code-archite… but interesting that V8 debug protocol is becoming more common, so maybe that will come to a browser some day :)
blakehaswell · 2021-10-26
Back in 2014 Spotify released some videos[1][2] about their engineering culture. From what I understand these were widely cited by consultants and the squad/tribe/chapter model was implemented verbatim at a number of companies. I'm guessing that is "getting Spotified".
[1]: https://engineering.atspotify.com/2014/03/27/spotify-engineering-cultu…
[2]: https://engineering.atspotify.com/2014/09/20/spotify-engineering-cultu…
thefreeman · 2021-10-09
This is much more excusable for email providers to prevent phishing. There are a ton of unicode points that indistinguishable from ascii letters. There are other security issues that can arise as well. Here is an example from spotify https://engineering.atspotify.com/2013/06/18/creative-usernames/