How Spotify Aligned CDN Services for a Lightning Fast Streaming Experience

How Spotify Aligned CDN Services for a Lightning Fast Streaming Experience

  • February 27, 2020
Table of Contents

How Spotify Aligned CDN Services for a Lightning Fast Streaming Experience

Spotify built its business on flawless content delivery. Our streaming platform serves up more than 50 million tracks (plus an array of images and other assets) to more than 230 million monthly active users around the world — making us one of the world’s leading streaming services. With content that feels instant and immersive, we help our customers have the best experience possible with their favorite artists.

Behind the scenes, our technology has evolved over time to achieve our user experience goals. After a decade of growth, we were using a number of disparate CDN solutions — which added complexity to our platform architecture, as well as inefficiency within the R&D organization. Spotify’s multi CDN strategy for audio streaming was working well.

However serving other types of content like images or client updates led us to create a new squad that focused on standardizing our CDNs using Fastly’s edge cloud platform across diverse engineering teams, as well as provide automated tools, governance, and support.

Source: spotify.com

Share :
comments powered by Disqus

Related Posts

Automating Datacenter Operations at Dropbox

Automating Datacenter Operations at Dropbox

Switch provisioning at Dropbox is handled by a Pirlo component called the TOR Starter. The TOR Starter is responsible for validating and configuring switches in our datacenter server racks, PoP server racks, and at the different layers of our datacenter fabric that connect racks in the same facility together. Writing the TOR Starter on top of the ClusterOps queue provides us with a basic manager-worker queuing service.

Read More
How we 30x’d our Node parallelism

How we 30x’d our Node parallelism

What’s the best way to safely increase parallelism in a production Node service? That’s a question my team needed to answer a couple of months ago. We were running 4,000 Node containers (or ‘workers’) for our bank integration service.

Read More
Taming ElastiCache with Auto-discovery at Scale

Taming ElastiCache with Auto-discovery at Scale

Our backend infrastructure at Tinder relies on Redis-based caching to fulfill the requests generated by more than 2 billion uses of the Swipe® feature per day and hosts more than 30 billion matches to 190 countries globally. Most of our data operations are reads, which motivates the general data flow architecture of our backend microservices.

Read More