System Requirements

Functional:

1. User Authentication
   1. Implement a safe user authentication system allowing users to create accounts, log-in, log-out securely
   2. Provide mechanisms for user registration, including validation for unique usernames and email addresses
   3. Ensure passwords are securely stored using encryption techniques and employ secure authentication protocols such as HTTPs and OAuth
2. Music Library
   1. Provide users with an access to an extensive music library with a wide range of songs, albums and artists, in multiple languages
   2. All the songs, albums and content should be well organized while allowing for searching based on title, genre, moods and other filters
3. Search and Recommendation
   1. Allows users to be able to search for a particular song, album, artist, playlist by keyword
   2. Utilize recommendation algorithms to to suggest personalized content based on the songs in the user's current playlist, listening history and preferences
4. Playlist Creation
   1. Enable users to create playlists by selecting songs from the music library
   2. Allow users to add, remove or reorder songs in their playlist
   3. Allow users to share playlists with other users, make them public or private
5. Streaming Quality
   1. Deliver high quality streams supporting various bit rates and codecs to accommodate different devices
   2. Implement adaptive streaming strategy to dynamically adjust audio quality based on network conditions and device capabilities
6. Cross Device Sync
   1. Ensure seamless synchronization of user data across multiple devices ensuring seamless playback
   2. Changes made in one device to the user data should reflect immediately on other logged in devices
7. Offline Mode
   1. Allow users to download songs, albums or playlists for offline listening
   2. Ensure downloaded content remains accessible offline until removed by the user

Non-Functional:

1. Security
   1. Ensure that user authentication adheres to industry standards with strong encryption algorithms used to encrypt user data
   2. Unauthorized access should never happen
2. Performance
   1. Ensure fast and responsive user authentication process, music streaming and synchronization to have a smooth user experience and decrease user wait times
   2. Minimize latency during search, updating profile, music playback
3. Reliability
   1. Ensure a high degree of uptime for our service, the service should continue to operate smoothly even in events when a part of the service is down or a network failure happens
   2. Implement data redundancy and fail-over mechanisms to mitigate the risk of data loss
4. Scalability
   1. Design a service to handle a growing user base, song library and increasing demand for music streaming services
   2. Handle traffic spikes which can happen when a popular artist publishes a new album or song etc.
5. Usability
   1. Design intuitive interfaces for authentication, media discovery, playlist creation, offline access catering to users of all skill levels
   2. Provide clear feedback and instructions to users during authentication, search and synchronization process

Capacity Estimation

1. User Metadata
   1. We assume that each user needs 1 MB of storage, we assume we would have a total of 1 billion users, thus we would need, 10^6 * 10^9 bytes = 10^15 bytes of data = 1 PB of data
   2. Factoring in redundancy, we can assume we need 5 PB data
2. Song Data
   1. We assume we have a total of 1 billion songs
   2. Each songs with its metadata takes roughly 10 MB data, since we will need to store songs in different bit rates
   3. Thus we would need 10^9 * 10 * 10^6 bytes of data = 10^16 = 10 PB data
   4. Factoring in redundancy, we can assume we need 50 PB data
3. Playlist Data
   1. We have assumed a total of 1 billion users (10^9)
   2. Let's assume each user stores 100 songs across all playlists on average
   3. We can assume that a playlist will use 1 KB data
   4. Thus, we would need 10^9 * 10^3 bytes = 10^12 bytes = 1 TB of data
   5. Factoring in redundancy, we can assume we need 5 TB data
4. User Subscription Data
   1. We assume we store 1 KB data for each user like payment information, subscription types etc.
   2. We assumed a total of 1 billion users
   3. Thus we would need 10^3 * 10^9 = 1 TB data
   4. Factoring in redundancy, we would need 5 TB data

Thus in total, we would need 5 PB + 50 PB + 5 TB + 5 TB of data, roughly 60 PB of data factoring in other costs

API Design

1. User Authentication APIs
   1. /register POST Register a new user
   2. /login POST Login en existing user
   3. /logout POST Logout an existing user
2. Music Library APIs
   1. /search GET Let users to search for songs, albums, playlists and artists
   2. /song/:songName GET Search for a song by name
   3. /album/:albumName GET Search for an album by name
   4. /artist/:artistName GET Search for an artist by name
3. Playlist Management APIs
   1. /playlists GET Get a user's playlists
   2. /playlists/:playListID GET Get a specific playlist
   3. /playlists/create POST Create a new playlist
   4. /playlists/add POST Add song to a playlist
   5. /playlists/remove PUT Remove song from playlist
   6. /playlists/:playListID/share GET Share a playlist with another user
4. Cross Device Sync APIs
   1. /sync GET Get user data for their profile
   2. /sync POST Make changes to user profile
5. Audio Streaming APIs
   1. /stream/:songID GET Stream a particular song
   2. /download/:songID Download a song
6. User Profile APIs
   1. /profile/:userID GET Get a user profile
   2. /profile/:userID PUT Update a user profile
   3. /profile/:userID DELETE Delete a user profile

Database design

We need to store three kinds of data, user data, song data and song metadata, playlist data.

1. User Data & Subscription Data
   1. For storing user data, we use a relational database since the data is highly structured and interconnected
   2. We can normalize data in the form of tables
   3. Here we focus on consistency since this is all critical data
2. Song Metadata & Playlist Data
   1. We can use a non-relational database like a document store or a key value store since we are not going to be making changes to this data, also we are not going to be querying this data all the time
   2. Here we have a balanced focus on consistency and availability
3. Song Data
   1. We can use Hadoop Distributed File System since it supports local processing, fault tolerance and redundancy

classDiagram class Users { + user_id + username + email + password + profile_picture + created_at } class Songs { + song_id + title + artist + album + genre + duration + file_path + file_size + bitrate + created_at } class Playlists { + playlist_id + user_id + name + created_at } class PlaylistSongs { + playlist_song_id + playlist_id + song_id } class UserSubscription { + subscription_id + user_id + subscription_type + start_date + end_date + payment_details } Users "1" --> "0..n" Playlists : Owns Playlists "1" --> "0..n" PlaylistSongs : Contains PlaylistSongs "0..n" --> "1" Songs : Includes Users "1" --> "1" UserSubscription : Has

The best partitioning strategy for this scenario would be based on user ID or geographic location ensuring that related data such as user profile data, user playlists are stored together to minimize cross partition queries and maximize performance

The hashing algorithm of choice would be consistent hashing algorithm to ensure that data is evenly distributed across data nodes and data accessibility is easy as well.

We can also store user data close to their geographic location for better performance and compliance with data privacy laws of the certain region

For the sharding strategy, we can shard data based on geographic location, ensuring that users from the same region have their data stored together.

All of our data stores are scaled horizontally to ensure data redundancy. When are choose a data node to write data to based on the consistent hashing algorithm, we can also replicate the same data to the next N nodes in the data store to ensure that data is being replicated, where N is a parameter we can decide based on our past experiences with data loss.

High-Level Design

1. Client Interface
   1. Web Interface
   2. Mobile Apps
   3. Desktop Apps
2. Authentication
   1. Authentication Services (OAuth)
3. User Management
   1. User Profile Management
   2. Subscription Management
   3. Preferences and Settings
4. Content Management
   1. Song Metadata Service
   2. Playlist Management
   3. Artist & Album Management
5. Media Streaming
   1. Media Server
   2. Content Delivery Network
   3. Bitrate Application
6. Recommendation Engine
   1. Recommendation Service
   2. Collaborative Filtering Algorithm
   3. Machine Learning Models
7. Search & Discovery
   1. Search Service
   2. Popular Content
8. Social Features
   1. Social Graph Management
   2. Social Sharing
   3. Activity Feeds
9. Analytics and Monitoring
   1. Monitoring System
   2. Usage Analytics
   3. Performance Monitoring
10. Infrastructure
    1. Load Balancers
    2. Caching Layer
    3. Database Clusters
    4. Content Delivery Network
    5. Container Orchestration (Docker, Kubernetes Swarm)
11. Billing and Payments
    1. Billing Service (Subscription Management, Invoicing)
    2. Payment Gateway Integration
    3. Revenue Reporting and Analytics

flowchart TD SpotifyApp[Spotify App] AuthS[AuthZ / AuthN Services] LB[Load Balancer] subgraph Databases SongsDB[Songs Database] PlaylistsDB[Playlists Metadata Database] UserSubscriptionDB[User Subscription Database] end subgraph MediaStreaming MediaServer(Media Server) CDN(Content Delivery Network) BitrateAdaptation(Bitrate Adaptation) end Recommendation_Engine BillingService subgraph UserServices UserProfile(User Profile Management) SubscriptionManagement(Subscription Management) PreferencesSettings(Preferences and Settings) end subgraph Analytics LoggingMonitoring(Logging and Monitoring System) UsageAnalytics(Usage Analytics) PerformanceMonitoring(Performance Monitoring) end SpotifyApp --> AuthS SpotifyApp --> LB LB --> BillingService LB --> UserServices LB --> MediaStreaming Recommendation_Engine --> Databases Recommendation_Engine --> SpotifyApp MediaStreaming --> SongsDB MediaStreaming --> PlaylistsDB Analytics --> Databases Analytics --> BillingService Analytics --> SpotifyApp UserServices --> Databases

Request Flows

sequenceDiagram participant User User->>Web: Open music streaming app Web->>User: Display app interface User->>Web: Search for songs Web->>Search: Perform search query Search-->>Web: Return search results Web-->>User: Display search results User->>Web: Select songs for playlist Web->>Playlist: Add selected songs to playlist Playlist-->>Web: Playlist updated Web-->>User: Confirmation message User->>Web: Create new playlist Web->>Playlist: Send request to create playlist Playlist-->>Web: Playlist created Web-->>User: Playlist creation success message User->>Web: Share playlist Web->>Social: Send share request Social-->>Web: Share operation completed Web-->>User: Share success message

Detailed Component Design

Media Service

1. Storage: The Media Server stores audio files, including songs, albums, and podcasts, in a distributed storage system optimized for efficient retrieval and streaming. It may use a combination of disk storage and in-memory caching for faster access to frequently requested content. Media Service also fetches data from Songs Metadata database to get the song title, description, artist information etc.
2. Streaming Protocol: When a user requests a song, the Media Service retrieves the corresponding audio file from storage and streams it to the user's device. It uses streaming protocols such as HTTP Live Streaming (HLS), MPEG-DASH, or RTMP (Real-Time Messaging Protocol) to deliver the audio data in chunks over the internet.
3. Bitrate Adaptation: The Media Server may implement bitrate adaptation techniques to optimize audio quality and playback performance based on the user's network conditions and device capabilities. It dynamically adjusts the bitrate of the streamed audio to maintain smooth playback and minimize buffering.
4. Load Balancing and Scalability: To handle a large number of concurrent streaming sessions, the Media Server employs load balancing techniques to distribute incoming requests across multiple server instances. It can scale horizontally by adding more server nodes to accommodate increasing user demand for streaming audio content.

Content Delivery Network (CDN)

1. Caching and Edge Servers: The CDN consists of a network of geographically distributed edge servers located close to the end-users. These edge servers cache copies of audio files and other static content, reducing the distance and latency between the user and the content.
2. Request Routing: When a user requests a song, the CDN's request routing system directs the request to the nearest edge server based on the user's geographical location, network conditions, and server availability. This minimizes latency and improves content delivery speed.
3. Content Replication: The CDN replicates popular audio files across multiple edge servers to ensure high availability and reliability. If one server becomes unavailable or experiences high traffic load, users can still access the content from other nearby servers.

Song Recommendation Engine

Recommendation Engines help user discover new content or suggest them trending content based on their location and preferences.

1. Data Collection and Processing:
   1. The Recommendation Engine collects user data, including listening history, ratings, likes, dislikes, and user interactions such as playlist creation and song skips.
   2. It preprocesses and analyzes this data to extract meaningful insights, such as user preferences, music genres, artist affinity, and contextual information.
2. Algorithm Selection: The Recommendation Engine employs various algorithms to generate personalized recommendations for users. These algorithms include:
   1. Collaborative Filtering: Identifies similarities between users or items based on their past interactions to recommend items liked by similar users.
   2. Content-Based Filtering: Recommends items similar to those the user has previously interacted with, based on attributes such as genre, artist, tempo, or mood.
   3. Matrix Factorization: Decomposes the user-item interaction matrix into latent factors to capture underlying patterns and make predictions.
   4. Hybrid Approaches: Combines multiple recommendation techniques to leverage their strengths and improve recommendation accuracy.
3. Real-Time Recommendations:
   1. The Recommendation Engine provides real-time recommendations as users interact with the music streaming service.
   2. It continuously updates recommendations based on user actions and feedback to adapt to changing preferences and trends.

Search Services

Search Service is one of the most essential services in this design, they help users search for content and hence these need to be extremely fast and reliable.

• Indexing and Query Processing:
  • The Search Service indexes a wide range of content, including songs, albums, artists, playlists, and user profiles. It uses indexing techniques such as inverted indexing to efficiently retrieve relevant results for user queries.
  • When a user performs a search query, the Search Service processes the query, matches it against the indexed content, and ranks the results based on relevance.
• Full-Text Search:
  • The Search Service supports full-text search capabilities, allowing users to search for content using keywords, phrases, or advanced search operators. It employs tokenization, stemming, and query expansion techniques to enhance search accuracy and recall.
• Faceted Search and Filtering:
  • The Search Service provides faceted search capabilities, allowing users to filter search results based on various attributes such as genre, release year, popularity, and user ratings. It enables users to narrow down their search results and discover content more efficiently.
• Autocomplete and Suggestions:
  • The Search Service offers autocomplete and query suggestion features to assist users in formulating their search queries. It predicts query completions based on user input and historical search patterns, helping users discover relevant content quickly.
• Scalability and Performance:
  • The Search Service is designed for scalability and performance to handle large volumes of search queries and concurrent users. It employs distributed indexing and query processing techniques, along with caching and replication strategies, to ensure low latency and high throughput.

Trade Offs/Tech Choices

1. Database Selection
   1. For our relational databases, we can choose Oracle MySQL
   2. For our non-relational database we will use a document store like MongoDB
   3. For our song metadata, we could have also used a relational database in place of a non-relational one since the size of the data is not large and it is well structured
2. Content Delivery Network (CDN)
   1. We could have also employed a CDN and stored all of the content that is currently very popular across the world or content that is currently very popular in a specific region for faster access and lower latency times
   2. Increases operational costs

Failure Scenarios/Bottlenecks

Concurrent Playlist Modifications by Multiple Users:

• Optimistic Locking: When a user retrieves a playlist for editing, the system attaches a version number or timestamp to the playlist data. Before saving changes, the system checks if the playlist has been modified by another user since it was last retrieved. If there are no conflicts, the changes are applied; otherwise, the user is notified of the conflict and prompted to resolve it.
• Conflict Resolution: If two users attempt to modify the same playlist simultaneously, the system employs conflict resolution mechanisms to reconcile conflicting changes. This could involve merging changes intelligently or allowing users to choose which changes to keep.
• No-Sql Database and Eventual Consistency: With our design for storing playlists in document db, the playlist can be updated by the system when it is done completing its current tasks, since the updates are not extremely crucial for the working of the app, the playlist can be eventually consistent will all the changes made by multiple users.

Playlist Access Control Mechanisms:

• Privacy Settings: Users can define privacy settings for their playlists, specifying whether a playlist is public, private, or shared with specific users or groups. The system enforces these settings to control who can view and edit the playlist.
• Role-Based Access Control (RBAC): Administrators or playlist owners can assign roles and permissions to users, determining their access levels to playlists. For example, some users may have read-only access, while others may have full editing privileges.

Offline Access and Syncing:

• Offline Mode: The system supports offline access to playlists and songs, allowing users to listen to music without an internet connection. Offline changes are queued and synchronized with the server when the device reconnects to the internet.
• Conflict Handling: In offline mode, conflicts may occur if the same playlist is modified on multiple devices without internet access. The system provides mechanisms for resolving conflicts when syncing changes made offline with the server.

Performance and Scaling during Peak Load

During peak usage periods, such as when a highly anticipated album release occurs or during major live events like music festivals, the demand for streaming audio content surges significantly.

To address potential performance bottlenecks in the media streaming service during such periods, a combination of scalable infrastructure and content distribution strategies is essential. For instance, consider a scenario where a popular artist releases a new album, resulting in a sudden influx of users accessing the streaming platform to listen to the tracks.

To mitigate performance issues,

• the streaming service can leverage auto-scaling mechanisms to dynamically provision additional media servers and resources in response to the increased demand.
• Load balancers can evenly distribute incoming traffic across these servers, ensuring that no single server becomes overwhelmed, thus maintaining optimal performance for all users.
• The streaming service can utilize a Content Delivery Network (CDN) to cache and distribute audio content closer to end-users. By caching frequently accessed audio files and metadata in edge servers located geographically closer to users, latency is minimized, and server load is reduced.

For example, when users across different regions simultaneously stream the new album, CDN caches serve the content locally, reducing the strain on origin servers and network bandwidth. These measures collectively ensure that users experience smooth and uninterrupted playback, even during peak usage periods, enhancing overall user satisfaction and retention.

Future Improvements

1. Machine Learning
   1. We can use machine learning algorithms to better cater suggested songs or albums to a user. We can use these algorithms to have a better understanding of the preferences of the user
   2. We can auto generate a playlist using this algorithm and suggest it to the user on a daily basis
2. Cross Device Experience
   1. Users should be able to start listening on one device and resume playback on another device where all logged in devices would keep a tab of the current media being played by the user