Spotify architecture overview in Microservices - Architecture Diagram

System Overview - Spotify architecture overview

Spotify is a music streaming service that lets users listen to songs on demand. It must handle millions of users streaming music simultaneously, provide personalized recommendations, and keep user data safe and synced across devices.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +-----------------------------+
  |                             |
  v                             v
User Service               Music Service
  |                             |
  v                             v
User Database             Music Database
  |                             |
  v                             v
Cache                      Cache
  |
  v
Recommendation Service
  |
  v
Message Queue
  |
  v
Analytics Service

Components

User

client

End user accessing Spotify app or web player

Load Balancer

load_balancer

Distributes incoming user requests evenly to API Gateway instances

API Gateway

api_gateway

Routes requests to appropriate microservices and handles authentication

User Service

service

Manages user profiles, authentication, and subscriptions

Music Service

service

Handles music catalog, streaming, and metadata

User Database

database

Stores user data like profiles, playlists, and preferences

Music Database

database

Stores music files metadata and catalog information

Cache

cache

Speeds up frequent data access for user and music data

Recommendation Service

service

Generates personalized music recommendations

Message Queue

message_queue

Handles asynchronous communication between services, e.g., analytics events

Analytics Service

service

Processes user behavior data for insights and improving recommendations

Request Flow - 14 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → User Service

User Service → Cache

Cache → User Service

User Service → User Database

API Gateway → Music Service

Music Service → Cache

Cache → Music Service

Music Service → Music Database

API Gateway → Recommendation Service

Recommendation Service → Message Queue

Message Queue → Analytics Service

API Gateway → User

Failure Scenario

Component Fails:Cache

Impact:Increased latency as services must query databases directly; higher load on databases

Mitigation:Databases are replicated and optimized for read-heavy loads; cache is restored asynchronously; fallback to DB queries ensures availability

Architecture Quiz - 3 Questions

Which component is responsible for distributing incoming user requests evenly?

A User Service

B API Gateway

C Load Balancer

D Message Queue

Design Principle

This architecture uses microservices to separate concerns like user management, music catalog, and recommendations. It employs caching to reduce database load and message queues for asynchronous processing, ensuring scalability and responsiveness.

Practice

1. What is the main reason Spotify uses microservices in its architecture?

easy

A. To avoid using APIs between components

B. To separate different tasks for better scalability and maintenance

C. To make the app use less memory on devices

D. To reduce the number of servers needed

Solution

1. Step 1: Understand microservices purpose

   Microservices split an app into small parts, each handling a specific task.

2. Step 2: Connect to Spotify's needs

   Spotify uses this to make the app scalable and easier to maintain by isolating tasks.

3. Final Answer:

   To separate different tasks for better scalability and maintenance -> Option B

4. Quick Check:

   Microservices = Separate tasks for scalability [OK]

Hint: Microservices split tasks for easier scaling and updates [OK]

Common Mistakes:

• Thinking microservices reduce memory usage directly
• Believing microservices avoid APIs
• Assuming microservices reduce server count

2. Which communication method is commonly used between Spotify's microservices?

easy

A. APIs and message queues

B. FTP file transfers

C. Shared memory

D. Direct database access

Solution

1. Step 1: Identify common microservice communication

   Microservices usually communicate via APIs or message queues for loose coupling.

2. Step 2: Match with Spotify's design

   Spotify uses APIs and message queues to keep services independent and responsive.

3. Final Answer:

   APIs and message queues -> Option A

4. Quick Check:

   Microservices communicate via APIs/message queues [OK]

Hint: Microservices talk via APIs or message queues, not direct DB [OK]

Common Mistakes:

• Choosing direct database access which breaks service independence
• Selecting shared memory which is uncommon in distributed systems
• Picking FTP which is unrelated to microservice communication

3. Consider a microservice that handles user playlists. If it receives a request to add a song, what is the likely flow in Spotify's architecture?

medium

A. The playlist service waits for the user to refresh the app manually

B. The playlist service directly modifies the recommendation service's database

C. The playlist service sends the request to the user interface to update

D. The playlist service updates its database and sends a message to the recommendation service

Solution

1. Step 1: Understand service responsibilities

   The playlist service manages playlists and updates its own data store.

2. Step 2: Recognize inter-service communication

   After updating, it informs other services like recommendations via messages.

3. Final Answer:

   The playlist service updates its database and sends a message to the recommendation service -> Option D

4. Quick Check:

   Playlist service updates DB + notifies others [OK]

Hint: Services update own data, notify others via messages [OK]

Common Mistakes:

• Assuming direct DB access across services
• Thinking UI triggers backend updates
• Believing manual refresh is needed for updates

4. A developer notices that Spotify's microservices sometimes fail to update user data consistently. What is a likely cause in the architecture?

medium

A. APIs are synchronous, causing delays

B. Services are directly sharing the same database without coordination

C. Message queues are not used, causing lost updates

D. Microservices are deployed on the same server

Solution

1. Step 1: Identify cause of inconsistent updates

   Without message queues, updates may be lost or not delivered reliably.

2. Step 2: Understand Spotify's architecture best practices

   Spotify uses message queues to ensure reliable communication and consistency.

3. Final Answer:

   Message queues are not used, causing lost updates -> Option C

4. Quick Check:

   Missing message queues = lost updates [OK]

Hint: Lost updates often mean missing message queues [OK]

Common Mistakes:

• Blaming shared database without evidence
• Confusing synchronous APIs with update loss
• Assuming deployment location causes data inconsistency

5. Spotify wants to add a new feature that recommends songs based on live user activity. Which architectural change fits best with their microservices approach?

hard

A. Create a new recommendation microservice that consumes live activity events via message queues

B. Add the recommendation logic directly inside the user interface code

C. Store all live activity data in a single monolithic database accessed by all services

D. Use FTP to transfer live activity logs to the recommendation service hourly

Solution

1. Step 1: Identify best practice for new feature in microservices

   Adding a new microservice keeps responsibilities separate and scalable.

2. Step 2: Use message queues for live data

   Consuming live events via message queues fits asynchronous, decoupled design.

3. Final Answer:

   Create a new recommendation microservice that consumes live activity events via message queues -> Option A

4. Quick Check:

   New microservice + message queues = best fit [OK]

Hint: New features get own microservice, use message queues for live data [OK]

Common Mistakes:

• Embedding logic in UI breaks separation
• Using monolithic DB reduces scalability
• FTP is outdated and slow for live data