Getting Ready: Music Streaming

Music streaming has transformed from a niche experiment into a $30+ billion industry. Spotify serves over 600 million users, with 220+ million paying subscribers who collectively stream over 4 billion tracks per day. Apple Music, Amazon Music, YouTube Music, and Tidal compete in the same space, each building sophisticated playback engines, recommendation systems, and subscription management layers.

The engineering challenge behind a music streaming service is deceptively rich. On the surface, it's "press play, hear music." In practice, the system must manage a catalog of 100+ million songs organized by artist, album, and genre; allow users to create, share, and collaboratively edit playlists; maintain a play queue that supports shuffle, repeat, and on-the-fly insertions; enforce subscription tiers where free users hear ads and premium users get offline downloads; and broadcast now-playing updates to social feeds, desktop/mobile clients, and scrobbling services — all in real time.

This problem is a favorite in LLD interviews at companies like Spotify, Amazon, Apple, and Netflix because it tests your ability to combine multiple design patterns into a cohesive system. You'll need the Iterator Pattern for playlist traversal (sequential, shuffled, repeat modes), the Observer Pattern for now-playing notifications, the Strategy Pattern for recommendation algorithms, and the Decorator Pattern for layering subscription features. It's one of the cleanest real-world demonstrations of how four patterns work together without stepping on each other's responsibilities.

By the end of this design problem, you will be able to:

• Model a media catalog with Song, Album, and Artist classes connected through composition and association
• Design a playlist system that supports ordered song collections, add/remove operations, and multiple traversal modes
• Implement a play queue with next/previous, shuffle (Fisher-Yates), and three repeat modes (OFF, ONE, ALL)
• Apply the Iterator Pattern to traverse playlists without exposing their internal list structure
• Apply the Observer Pattern to broadcast now-playing events to multiple subscribers (UI, social feed, scrobbler)
• Apply the Decorator Pattern to layer subscription features (ad-free, offline, high-quality audio) onto a base plan
• Apply the Strategy Pattern to swap recommendation algorithms at runtime
• Build the complete system in both Python and Java with a realistic driver example
• Draw UML class and sequence diagrams that trace directly to requirements

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition (Song belongs to Album) and Association (Playlist references Songs) (Fundamentals S4)
• Iterator Pattern — how to traverse a collection without exposing its internals (Fundamentals S12)
• Observer Pattern — publish-subscribe for event notification (Fundamentals S12)
• Decorator Pattern — wrapping objects to add behavior dynamically (Fundamentals S11)
• Strategy Pattern — interchangeable algorithms behind a common interface (Fundamentals S12)
• UML Class Diagrams — reading classes, attributes, methods, and relationship arrows (Fundamentals S5)
• UML Sequence Diagrams — understanding lifelines, messages, and activation bars (Fundamentals S5)

If you've completed the Medium-difficulty problems (DP8–DP18), you're well prepared. This Hard problem introduces the Decorator Pattern for subscriptions, which wasn't needed in the Medium tier.

We will design: The core domain logic of a music streaming service — the song/album/artist catalog, user accounts and subscriptions, playlist management, the play queue with shuffle and repeat, the music player with playback controls, and a notification system for now-playing updates.

We will NOT design: Audio encoding/decoding, CDN-based audio delivery, distributed storage, REST APIs, database schemas, the recommendation ML pipeline, or the frontend UI. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Complexity: Hard — 12-18 classes, 4 design patterns, 2 UML diagram types (class + sequence), a dedicated algorithm tutorial (playlist/queue management), and a dedicated extension tutorial (subscription tiers with Decorator).

To design well, we need to understand the real domain:

Catalog structure: Music is organized hierarchically. An Artist produces Albums, and each Album contains Songs (tracks). A song has metadata (title, duration, genre) and an audio reference (URI to the actual audio file). Songs can appear in multiple playlists and multiple user queues simultaneously — the song object is shared, not copied.

Playlists: A playlist is an ordered collection of song references owned by a user. Unlike an album (which is immutable once released), a playlist is mutable — songs can be added, removed, and reordered. Playlists can be public (discoverable by other users) or private. Spotify's "Liked Songs" is a special system-managed playlist.

Play queue: When you play a playlist, the songs are loaded into a play queue. The queue is separate from the playlist itself — you can add songs to "Play Next" without modifying the playlist. The queue tracks the current position, supports next/previous navigation, and handles shuffle mode (randomize order) and repeat mode (OFF: stop at end, ONE: loop current song, ALL: loop back to start).

Shuffle algorithm: Spotify uses a modified Fisher-Yates shuffle — it generates a random permutation of the playlist indices and plays songs in that shuffled order. When you toggle shuffle off, it returns to the original sequential order from the current position.

Subscriptions: Spotify has tiered subscriptions. Free users get ads between songs and can't skip unlimited times. Premium users get ad-free playback, offline downloads, and higher audio quality. Family plans share a single billing but give each member their own Premium features. This is a textbook Decorator Pattern scenario — each tier wraps additional capabilities around a base subscription.

Now-playing updates: When the current song changes, multiple systems need to react: the UI updates the song info and progress bar, the social feed shows what friends are listening to, and external scrobbling services (like Last.fm) log the play. This is a classic Observer Pattern — the player is the subject and all these listeners are observers.