Spotify architecture overview in Microservices - System Design Exercise

Design: Spotify Music Streaming Service

Design covers backend microservices, data storage, streaming delivery, and user interaction APIs. Does not cover detailed frontend UI design or DRM encryption specifics.

Functional Requirements

FR1: Allow users to search and play music tracks instantly

FR2: Support personalized playlists and recommendations

FR3: Handle millions of concurrent users streaming music

FR4: Provide offline playback for subscribed users

FR5: Allow users to follow artists and share playlists

FR6: Support multiple devices and platforms (mobile, desktop, web)

FR7: Ensure high availability and low latency for streaming

FR8: Provide analytics on user listening behavior

Non-Functional Requirements

NFR1: Scale to 100 million monthly active users

NFR2: API response time p99 under 200ms for search and playback requests

NFR3: Streaming latency under 1 second from request to playback start

NFR4: Availability target of 99.9% uptime

NFR5: Data consistency for user playlists and subscriptions

NFR6: Support global distribution with data centers in multiple regions

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

User Service for authentication and profiles

Music Catalog Service for metadata management

Streaming Service for audio delivery

Playlist Service for user playlists

Recommendation Service for personalized suggestions

Search Service for fast music lookup

Analytics Service for user behavior tracking

Content Delivery Network (CDN) for global streaming

Cache layers for metadata and popular tracks

Design Patterns

Microservices architecture with API Gateway

Event-driven communication for updates and analytics

CQRS for separating read and write workloads

Cache-aside pattern for metadata caching

Circuit breaker for service resilience

Data partitioning and sharding for scale

Use of CDN for content distribution

Reference Architecture

                    +---------------------+
                    |     User Devices     |
                    | (Mobile, Desktop, Web)|
                    +----------+----------+
                               |
                               v
                    +---------------------+
                    |     API Gateway     |
                    +----------+----------+
                               |
       +-----------------------+-----------------------+
       |                       |                       |
+--------------+       +---------------+       +--------------+
| User Service |       | Search Service|       |Playlist Svc  |
+--------------+       +---------------+       +--------------+
       |                       |                       |
       v                       v                       v
+--------------+       +---------------+       +--------------+
| Auth & Profile|      | Music Catalog |       |Recommendation|
+--------------+       +---------------+       +--------------+
       |                       |                       |
       +-----------+-----------+-----------+-----------+
                   |                       |
                   v                       v
           +---------------+       +----------------+
           | Streaming Svc |       | Analytics Svc  |
           +---------------+       +----------------+
                   |
                   v
           +----------------+
           | Content Delivery|
           | Network (CDN)   |
           +----------------+

Components

API Gateway

Nginx / Envoy

Entry point for all client requests, routes to appropriate microservices, handles authentication and rate limiting

User Service

Spring Boot / Node.js microservice

Manages user authentication, profiles, subscriptions, and device management

Search Service

Elasticsearch

Provides fast search capabilities over music metadata

Music Catalog Service

PostgreSQL / Cassandra

Stores music metadata like tracks, albums, artists, genres

Playlist Service

MongoDB / DynamoDB

Manages user playlists, sharing, and collaborative editing

Recommendation Service

Python microservice with ML models

Generates personalized music recommendations based on user behavior

Streaming Service

Custom streaming servers with HLS/DASH

Delivers audio streams to users with low latency

Analytics Service

Kafka + Hadoop / Spark

Collects and processes user listening data for insights and recommendations

Content Delivery Network (CDN)

Akamai / Cloudflare

Caches and delivers audio content globally to reduce latency

Request Flow

1. User opens app and authenticates via API Gateway to User Service

2. User searches for a song; request routed to Search Service querying Elasticsearch

3. Search Service fetches metadata from Music Catalog Service if needed

4. User selects a track to play; Streaming Service is requested via API Gateway

5. Streaming Service fetches audio files from CDN or origin storage

6. User creates or modifies playlists via Playlist Service

7. Recommendation Service updates suggestions based on user activity events

8. Analytics Service consumes event streams for user behavior analysis

9. CDN caches popular audio content close to user location for fast delivery

Database Schema

Entities: - User: user_id (PK), email, password_hash, subscription_status, created_at - Device: device_id (PK), user_id (FK), device_type, last_active - Track: track_id (PK), title, artist_id (FK), album_id (FK), duration, genre - Artist: artist_id (PK), name, bio - Album: album_id (PK), title, artist_id (FK), release_date - Playlist: playlist_id (PK), user_id (FK), name, is_public - Playlist_Track: playlist_id (FK), track_id (FK), position - Listening_Event: event_id (PK), user_id (FK), track_id (FK), timestamp, device_id (FK) Relationships: - User to Device: 1 to many - Artist to Album: 1 to many - Album to Track: 1 to many - User to Playlist: 1 to many - Playlist to Track: many to many via Playlist_Track - User to Listening_Event: 1 to many

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure under high load

Search Service latency increasing with growing music catalog

Streaming Service bandwidth and server capacity limits

Database write contention on Playlist and Listening_Event tables

Recommendation Service model training and inference delays

Analytics pipeline lag with large event volumes

Solutions

Deploy multiple API Gateway instances behind a load balancer with health checks

Partition search index by genre or region; use replicas for read scaling

Use CDN aggressively to offload streaming traffic; autoscale streaming servers

Shard databases by user ID; use write-optimized stores for event data

Use incremental and distributed model training; cache recommendations

Implement real-time streaming analytics with scalable frameworks like Apache Flink

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain microservices choice for modularity and independent scaling

Discuss caching and CDN use to reduce latency for streaming

Highlight separation of concerns: search, streaming, recommendations

Mention data consistency and eventual consistency trade-offs

Address global distribution and multi-region deployment

Talk about monitoring, logging, and fault tolerance strategies