Requirements for the Streaming Service

Let's define what our Music Streaming Service needs to do. Each requirement is specific enough to drive a class, method, or relationship in our design.

Catalog & Browsing:

1. R1 — Song catalog: The system shall maintain a catalog of songs, where each song has a title, artist, album, duration, genre, and an audio source reference.
2. R2 — Album grouping: Songs shall be organized into albums. Each album belongs to a single artist and contains one or more songs in a defined track order.
3. R3 — Artist profiles: The system shall support artist profiles with a name, biography, and a list of their albums.
4. R4 — Search: Users shall be able to search for songs, albums, and artists by name or keyword.

Playlists:

5. R5 — Create/delete playlists: Users shall be able to create named playlists and delete playlists they own.
6. R6 — Add/remove songs: Users shall be able to add songs to and remove songs from their playlists. A song can appear in multiple playlists.
7. R7 — Playlist visibility: Playlists shall be either public (discoverable by other users) or private (visible only to the owner).

Playback:

8. R8 — Play controls: The music player shall support play, pause, stop, skip-next, and skip-previous operations.
9. R9 — Play queue: When a user plays a playlist or album, the system shall load songs into a play queue. Users shall also be able to add individual songs to the queue ("Play Next" and "Add to Queue").
10. R10 — Shuffle mode: The player shall support a shuffle mode that randomizes the play order using a fair shuffle algorithm (Fisher-Yates). Toggling shuffle off returns to the original sequential order.
11. R11 — Repeat modes: The player shall support three repeat modes: OFF (stop after last song), ONE (repeat current song), and ALL (loop back to the first song after the last).
12. R12 — Now-playing notifications: When the currently playing song changes, the system shall notify all registered observers (UI components, social feed, scrobbling services).

Subscriptions:

13. R13 — Subscription tiers: The system shall support at least two subscription tiers: Free (with ads, limited skips) and Premium (ad-free, unlimited skips, offline downloads, high-quality audio).
14. R14 — Feature gating: Playback features (ad-free, skip limit, audio quality, offline downloads) shall be determined by the user's subscription tier. Upgrading or downgrading tiers must change available features without modifying the player logic.

User Management:

15. R15 — User accounts: Each user has a unique username, email, and an associated subscription. A user owns zero or more playlists and has a listening history.

Beyond functional behavior:

1. NF1 — Extensibility: Adding a new subscription tier (e.g., Family, Student) must not require modifying existing subscription or player classes — the Decorator Pattern must make this a plug-in operation.
2. NF2 — Extensibility (recommendations): Swapping the recommendation algorithm (collaborative filtering, content-based, hybrid) must be possible at runtime without changing the service layer — the Strategy Pattern must enable this.
3. NF3 — Loose coupling (notifications): Adding a new now-playing observer (e.g., a new analytics service) must not require changes to the MusicPlayer — the Observer Pattern must ensure this.
4. NF4 — Encapsulation (playlist traversal): External code should traverse a playlist's songs without accessing the internal list directly — the Iterator Pattern must provide this abstraction.
5. NF5 — Testability: Each component (Player, Queue, Playlist, Subscription) must be testable in isolation with mock dependencies.

In Scope:

• Song, Album, Artist catalog model
• Playlist creation, editing, and traversal
• Play queue with shuffle and repeat modes
• Music player with playback controls and now-playing notifications
• Subscription tiers with feature gating (Decorator)
• Search for songs, albums, and artists
• User accounts and listening history

Out of Scope:

• Audio file storage, encoding, or CDN delivery — we model a song's audio source as a URI string, not the actual streaming infrastructure
• Recommendation ML models — we define a RecommendationStrategy interface but don't implement ML algorithms
• Social features beyond now-playing (following users, collaborative playlists, messaging)
• Payment processing — we model subscription tiers, not Stripe/PayPal integration
• REST APIs, database schemas, microservice architecture — this is an OOP design, not system design
• Ads engine — Free-tier "has ads" is a feature flag on the subscription, not a full ad-serving system

Every requirement drives at least one design element:

Requirement	Design Element
R1 (Song catalog)	Song class with title, artist, album, duration, genre, audioUri
R2 (Album grouping)	Album class composing a list of Song objects
R3 (Artist profiles)	Artist class associated with Album objects
R4 (Search)	MusicLibrary.search() method
R5 (Create/delete playlists)	User.createPlaylist(), User.deletePlaylist()
R6 (Add/remove songs)	Playlist.addSong(), Playlist.removeSong()
R7 (Playlist visibility)	Playlist.isPublic boolean field
R8 (Play controls)	MusicPlayer.play(), .pause(), .stop(), .next(), .previous()
R9 (Play queue)	PlayQueue class with addNext(), addToEnd()
R10 (Shuffle)	PlayQueue.toggleShuffle() using Fisher-Yates
R11 (Repeat modes)	RepeatMode enum (OFF, ONE, ALL) on PlayQueue
R12 (Now-playing notifications)	PlayerObserver interface + MusicPlayer.notifyObservers()
R13 (Subscription tiers)	Subscription base + PremiumDecorator, FamilyDecorator
R14 (Feature gating)	Subscription.canSkip(), .isAdFree(), .getAudioQuality()
R15 (User accounts)	User class with username, email, subscription, playlists, history

In a real interview, spend 3-5 minutes clarifying requirements before designing. Ask questions like:

• "Should we model collaborative playlists where multiple users can edit the same playlist?" — clarifies R5/R6 scope
• "How many subscription tiers? Just Free and Premium, or also Family and Student?" — clarifies R13 complexity
• "Do we need offline mode, or just streaming?" — clarifies R14 feature set
• "Is the recommendation system in scope, or just the interface?" — clarifies boundary
• "Should the play queue persist across sessions, or is it in-memory only?" — clarifies R9 durability

Establishing scope early prevents designing a system that's either too small ("it's just a play button") or too large ("let me design the entire Spotify infrastructure").