Spotify System Architecture: Microservices, Event Delivery, and Google Cloud

Spotify's backend is a set of several hundred microservices, mostly written in Java, running on Kubernetes in Google Cloud. Each service is owned by one small team, called a squad. Backstage, which Spotify built and later open-sourced, is the catalog that tells engineers what every service is and who owns it. Audio files are served through content delivery networks, and every user action becomes an event in a pipeline that peaks above 8 million events per second.

That is the architecture at the level a system design interview needs. The rest of this page explains each part and gives you a walkthrough you can draw on a whiteboard.

The main parts

Two decisions explain most of this table. Spotify split into microservices early so that squads could deploy independently. Then it moved everything from four of its own data centers to Google Cloud, so that the squads could stop running infrastructure.

A numbered walkthrough: pressing play

1. The client asks the access point for a track. The request includes the user's session and the track identifier.
2. The playback service checks the user's rights. A free user and a premium user get different answers, and a track that is not licensed in the user's country is refused.
3. The metadata services answer in parallel. Track, album, and artist details come from separate services, each with its own store. This is the microservice pattern: one team owns one kind of data.
4. The client fetches audio from a CDN. The backend returns where the audio lives, not the audio itself. The client then streams segments from the nearest CDN edge, which is why the backend can be far away without a delay you notice.
5. The client sends events. A play start, a skip, and a completed track each become an event.
6. The event pipeline stores and processes the events. They feed Discover Weekly, Wrapped, royalty reports, and A/B test results.

In an interview, draw steps 1 to 4 as the request path and steps 5 to 6 as the asynchronous path. Interviewers look for that separation.

The event delivery pipeline

Event delivery is the part of Spotify's architecture with the most published numbers. Spotify has stated that the system handles more than 500 distinct event types and more than 350 terabytes of raw events a day, with a peak above 8 million events per second.

The pipeline began on self-managed Apache Kafka. Spotify ran the Kafka system and a Cloud Pub/Sub system side by side for about a year, compared the data, and then shut Kafka down. Downstream, Dataflow jobs written with Scio, Spotify's Scala library for Apache Beam, clean and deduplicate the events into Cloud Storage and BigQuery.

The lesson for a design interview is that the choice was not about throughput. Both systems could handle the load. The choice was about who does the operational work.

Why microservices worked for Spotify

Microservices matched Spotify's team structure. A squad owns a service end to end: code, deployment, and on-call. Because each service has its own store, one squad's schema change cannot break another squad's release.

The cost was duplication. Each squad built its own deployment pipeline and monitoring, and Spotify has said it ended up with many versions of the same tooling. Backstage was the fix: one catalog, one set of templates, and a supported default path for building a new service, which Spotify calls a Golden Path.

Spotify also moved its container scheduling from Helios, its own tool, to Kubernetes. The reason was the same: less tooling to maintain in-house.

How to present Spotify in a system design interview

1. State the requirements: stream audio with low start delay, keep playlists and library data consistent per user, and collect events for personalization.
2. Draw the request path through an access point to independent services.
3. Put audio on a CDN and explain that the backend returns locations, not bytes.
4. Add the event pipeline as an asynchronous path with a queue and a batch layer.
5. Discuss the trade-off you would be asked about: per-service databases give independence but make cross-service queries hard.

For the design questions Spotify actually asks, read the top system design interview questions for Spotify. For the loop itself, read what the Spotify interview process is like.