Guides

Spotify Architecture Explained: How Spotify Runs on Google Cloud

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: Spotify runs on Google Cloud Platform (GCP). It moved there from its own data centres starting in 2015. Today thousands of small microservices, many on Kubernetes, power the app. Online data lives in Cloud Bigtable (petabytes), events flow through Cloud Pub/Sub, and exabytes of data sit in a Google Cloud Storage data lake (2026). Spotify also created Backstage, the developer portal now hosted by the CNCF.

Suppose you play your Discover Weekly playlist

It is Monday morning in Chennai. You open Spotify and play Discover Weekly. In simple terms:

1. The app calls Spotify's backend on Google Cloud.
2. Small services handle your login, your playlists, search and recommendations.
3. Your personalised data, such as listening history, is read from Bigtable.
4. The audio is streamed to your phone. How Spotify delivers audio files (which CDN) is not publicly shared.
5. Each play sends an event into Spotify's event delivery system on Cloud Pub/Sub.
6. These events land in the data lake and are used to build next week's playlist and your year-end Wrapped.

What architecture style does Spotify use?

Spotify is known for many small autonomous teams, each owning its own services.

1. Microservices at large scale: before the move, Spotify ran about 2,000 services and 20,000 daily data pipelines (2019); by 2023 it had tens of thousands of services and hundreds of thousands of cloud resources.
2. Declarative infrastructure (2023): teams describe the cloud resources they want in code, and Kubernetes-style controllers create and fix them.
3. Fleet management (2023): automated changes are rolled out across thousands of components, so teams do not upgrade everything by hand.
4. Indexed data lake (2026): petabytes live in Bigtable for online use, but exabytes sit in the GCS data lake. Spotify built Random Access Parquet so services and AI agents can look up one user's data straight from lake files.
5. Backstage: a developer portal that lists every service and its owner; Spotify open-sourced it and it is now a CNCF project. Spotify also offers it as a hosted product (Spotify Portal).

Spotify architecture diagram (public parts)

This diagram shows only what Spotify or its partners have shared publicly. Press Play to follow a request step by step.

What does Spotify use? Main technologies

Which cloud provider does Spotify use?

Spotify uses Google Cloud Platform. In 2019 Spotify chose to go all-in with a single cloud provider instead of multi-cloud or hybrid, and picked GCP.

How it started: own data centres and the move to Google Cloud (2015 to 2019)

1. Spotify launched in 2008 on its own servers, in four regions of co-located data centres.
2. By 2015 this meant about 2,000 services, 20,000 daily pipeline runs and over 100 petabytes of data.
3. In early 2015 Spotify began planning its cloud move and chose Google Cloud.
4. The old way was self-run Cassandra, Kafka, Elasticsearch, PostgreSQL and Memcached; in the cloud these became Bigtable, Pub/Sub and managed services.
5. Event delivery was rebuilt on Cloud Pub/Sub, running in the cloud for 2.5 years by late 2019.

How does Spotify store data?

1. Cloud Bigtable: petabytes of data for online features (2026).
2. Google Cloud Storage: an exabyte-scale data lake in Parquet files.
3. BigQuery and Trino are used for analytics over the lake.
4. Audio file storage and CDN details are not publicly shared.

How does Spotify monitor its systems?

1. Backstage gives each service a page with its owner, docs and health.
2. The exact metrics and alerting stack used today is not publicly shared.

If we built an app like Spotify on AWS (illustrative)

Suppose you want to build "SurSangam", a music streaming app for Indian classical music. Here is a simple AWS layout.

1. Network: VPC, subnets, route tables, gateways

1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

1. ALB in public subnets.
2. Music services on EKS in private subnets.
3. Play events go to Kinesis, then to S3 for analytics.

3. Storage and databases

1. S3 + CloudFront for audio files (with DRM where needed).
2. Aurora for the catalog.
3. DynamoDB for play history and playlists.
4. ElastiCache for hot data; Athena to query the S3 data lake.

4. Monitoring

1. CloudWatch dashboards and alarms.
2. X-Ray traces.
3. A service catalog like Backstage to track owners.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

Spotify versus our AWS design