Building a music streaming service that scales to millions of users while fairly compensating artists is one of the trickiest challenges in modern system design. The architecture must juggle real-time playback tracking, complex royalty calculations, offline syncing, and social features, all while maintaining consistency across distributed systems. Getting this right means the difference between a service users trust and one that leaves artists underpaid.
Architecture Overview
A robust music streaming platform requires careful separation of concerns across multiple layers. At its core, you need a playback service that handles real-time audio delivery with minimal latency, backed by a content delivery network to serve millions of simultaneous streams. Alongside this sits a metadata service managing song information, artist details, and catalog management. The library and playlist system maintains user-specific data with high availability, while an offline sync layer enables users to download tracks and access them without internet connectivity.
The social and discovery layer adds another dimension, handling user interactions like follows, shares, and recommendations. This typically integrates with a messaging or notification system to alert users about new releases from followed artists. Meanwhile, a dedicated royalty tracking system runs in parallel, logging every playback event with precision. This system doesn't just record that a song was played, it captures duration, timestamp, user tier, and region information, feeding into analytics pipelines that calculate payments to rights holders.
What ties everything together is an event streaming architecture. Every user interaction, from hitting play to skipping a track, becomes an immutable event flowing through the system. These events populate the royalty ledger, feed analytics dashboards, and power personalization algorithms. Using event sourcing here provides an audit trail that's critical for handling disputes and regulatory compliance across different countries.
Design Insight: Royalty Calculations
Here's where things get nuanced. When a user listens to just 10 seconds of a song, most streaming services don't count that as a full play for royalty purposes. Spotify, for example, requires at least 30 seconds of listening before it counts toward artist payments. The royalty calculation system tracks the actual duration listened, not the duration available. A 10-second snippet might generate a micro-payment of perhaps 1-3% of a full-play royalty, depending on the licensing agreement with that particular rights holder.
This creates an interesting architectural problem. The royalty system must reconcile playback logs against licensing agreements that vary by region, artist, and sometimes even album. A central rules engine evaluates these conditions in real-time or near-real-time, applying region-specific rates and minimum thresholds. When you multiply this logic across billions of monthly streams, the system needs to be highly efficient and fault-tolerant. That's why many platforms batch-process final calculations nightly but maintain real-time estimates for dashboard visibility.
Watch the Full Design Process
See how this architecture comes together in real-time with InfraSketch:
This is Day 59 of our 365-day system design challenge, demonstrating how InfraSketch transforms a complex requirement into a coherent architecture in minutes, not hours.
Try It Yourself
Head over to InfraSketch and describe your system in plain English. In seconds, you'll have a professional architecture diagram, complete with a design document.
Top comments (0)