Bird
Raised Fist0

Spotify - Audio Streaming, Playlist, Offline Download Architecture

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Design Spotify - Audio Streaming, Playlist, Offline Download Architecture
45 min · senior
senior

Design a music streaming platform serving 50M daily active users (DAU) with encrypted audio streaming, personalized playlists, and offline download support. The system must maintain P99 latency under 200ms for streaming start, support offline playback with DRM, and handle high concurrency with consistent playlist updates.

Constraints
  • End-to-end encryption of audio streams to prevent unauthorized access
  • Offline download with DRM license management and playback restrictions
  • P99 streaming start latency under 200ms globally
  • Support for 50M DAU with peak concurrency of 10M simultaneous streams
  • Playlist updates must be strongly consistent and reflected in real-time
  • Efficient storage and delivery of large audio files with CDN integration
📋
Guided Steps
1/5
Step 1
Design Audio Streaming Architecture
How would you architect the audio streaming pipeline to meet P99 < 200ms start latency and support 10M concurrent streams with encryption?
💡 Hint
Consider CDN edge caching, chunked streaming protocols, and encryption key delivery mechanisms.
Key Decision
Use HLS/DASH chunked streaming served via AWS CloudFront CDN with AES-128 encryption and DRM key delivery through AWS KMS integrated with a License Server for secure key exchange.
Interviewer Expectation
Mid: Names CDN and chunked streaming protocols. Senior: Explains CDN edge caching reduces latency globally, chunked streaming enables fast start, and secure DRM key delivery via KMS License Server prevents key leakage.
⚠️Common Wrong Answer
Serving entire audio files from origin servers without CDN - causes high latency and origin overload at 10M concurrent streams.
Step 2
Design Playlist Management System
How would you design the playlist service to support strong consistency, real-time updates, and scale to 50M DAU?
💡 Hint
Think about database choice for high write throughput and low-latency reads, and how to propagate updates to clients.
Key Decision
Use Apache Cassandra with playlist_id as partition key for linear write scalability and range queries, combined with Apache Kafka for event-driven real-time playlist update propagation to clients.
Interviewer Expectation
Mid: Mentions Cassandra for scalability. Senior: Explains Cassandra’s LSM-tree write path enables linear scaling, partition key choice ensures efficient range scans, and Kafka event streams enable real-time client sync with exactly-once semantics.
⚠️Common Wrong Answer
Using relational databases with strong consistency but poor horizontal scalability, leading to write bottlenecks and high latency.
Step 3
Design Offline Download and DRM License Management
How would you enable offline downloads with DRM license acquisition and renewal to enforce playback restrictions securely?
💡 Hint
Consider secure license servers, token-based authentication, and license expiration handling.
Key Decision
Implement a DRM License Server using Widevine or FairPlay integrated with OAuth 2.0 token authentication; licenses are short-lived and renewed via secure API calls, with offline playback enforced by encrypted media extensions (EME) on client devices.
Interviewer Expectation
Mid: Names DRM license server and token auth. Senior: Details license short TTLs, secure token exchange, offline license caching, and client-side enforcement via EME to prevent unauthorized playback.
⚠️Common Wrong Answer
Allowing offline playback without license renewal or secure token validation, risking piracy and license abuse.
Step 4
Design Audio Storage and Delivery
How would you store and deliver large audio files efficiently at scale with encryption and CDN integration?
💡 Hint
Think about object storage, multi-region replication, and integration with CDN for low latency.
Key Decision
Store audio files in Amazon S3 with multi-AZ replication and lifecycle policies; integrate with AWS CloudFront CDN for global edge caching; encrypt files at rest with SSE-S3 and in transit with TLS; use signed URLs for secure access.
Interviewer Expectation
Mid: Mentions S3 and CDN. Senior: Explains multi-AZ replication for durability, SSE-S3 for at-rest encryption, signed URLs prevent unauthorized access, and CDN edge caching reduces latency and origin load.
⚠️Common Wrong Answer
Serving audio directly from a single data center or VM storage causing high latency and single points of failure.
Step 5
Design Client-Server Synchronization for Playlists and Playback State
How would you ensure clients have consistent playlist and playback state across devices and offline scenarios?
💡 Hint
Consider event sourcing, conflict resolution, and local caching strategies.
Key Decision
Use Kafka event streams for playlist and playback state changes with client-side local caching and conflict resolution via vector clocks; sync occurs on app start and periodically, with offline changes queued and reconciled on reconnect.
Interviewer Expectation
Mid: Mentions local caching and sync. Senior: Explains event sourcing with Kafka ensures ordered updates, vector clocks resolve conflicts, and offline queuing prevents data loss with eventual consistency guarantees.
⚠️Common Wrong Answer
No offline sync or conflict resolution, causing data loss or inconsistent playlist states across devices.
🔌
API Design Challenge
Sketch 3 core API endpoints for the system: streaming audio, managing playlists, and offline download license acquisition.
Hints
  • How does the client request and receive an encrypted audio stream?
  • How does the client create, update, and fetch playlists with consistency?
  • How does the client acquire and renew DRM licenses for offline playback?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of CDN (AWS CloudFront) for low-latency global audio delivery
  • Encrypted streaming with DRM key management (AWS KMS License Server)
  • Scalable playlist storage with Apache Cassandra partitioned by playlist_id
  • Real-time playlist update propagation using Apache Kafka event streams
Good to Have - 30%
  • Offline download DRM license management with token-based authentication
  • Multi-AZ replicated object storage (Amazon S3) with encryption at rest
  • Client-side local caching and conflict resolution for offline sync
Bonus - 10%
  • Detailed API design for streaming, playlist management, and offline license acquisition
Anti-patterns to Avoid
✅
Model Answer
▼ Reveal

This design outlines a scalable, low-latency, and secure music streaming platform supporting 50M DAU with encrypted streaming, real-time playlist management, and offline playback with DRM enforcement.

Key Decisions
  • Use chunked streaming protocols (HLS/DASH) with AWS CloudFront CDN to achieve P99 start latency under 200ms at 10M concurrent streams
  • Encrypt audio streams with AES-128 and deliver DRM keys securely via AWS KMS License Server to prevent unauthorized access
  • Store playlists in Apache Cassandra partitioned by playlist_id to enable linear write scalability and efficient range queries
  • Propagate playlist updates and playback state changes via Apache Kafka event streams to ensure strong consistency and real-time client sync
  • Implement DRM License Server with OAuth 2.0 token authentication for secure offline license management with short TTLs and renewal APIs
  • Store audio files in Amazon S3 with multi-AZ replication and SSE-S3 encryption, accessed through signed URLs integrated with CloudFront CDN for secure, low-latency delivery
  • Enable client-side local caching and conflict resolution using vector clocks and offline queuing to maintain consistent playlist and playback state across devices and offline scenarios
  • HLS/DASH chunked streaming via AWS CloudFront CDN reduces P99 start latency below 200ms by caching audio chunks at edge locations.
  • AES-128 encryption with DRM key delivery through AWS KMS License Server ensures end-to-end encrypted audio streams preventing unauthorized access.
  • Apache Cassandra with playlist_id partition key enables linear write scalability and efficient range queries for playlist data at 50M DAU scale.
  • Apache Kafka event streams propagate playlist updates in real-time to clients, enabling strong consistency and low-latency sync.
  • DRM License Server (Widevine/FairPlay) with OAuth 2.0 token authentication manages offline license issuance and renewal securely.
  • Amazon S3 multi-AZ replicated storage with SSE-S3 encryption stores large audio files durably and securely.
  • Signed URLs integrated with CloudFront CDN enforce secure, time-limited access to audio content.
  • Client-side local caching with Kafka event sourcing and vector clocks enables offline playlist and playback state sync with conflict resolution.

Practice

(1/5)
1. In a directory-based sharding system, at step 3 the Shard Lookup Service receives a request for user ID 12345. What happens next?
easy
A. The service queries a centralized directory to find the exact shard assigned to user ID 12345
B. The service uses range boundaries to determine the shard for user ID 12345
C. The service forwards the request to all shards to find user ID 12345
D. The service hashes the user ID and routes to a shard based on the hash modulo shard count

Solution

  1. Step 1: Understand directory-based sharding

    Directory-based sharding uses a centralized mapping from keys to shards.

  2. Step 2: Trace step 3 action

    The Shard Lookup Service consults the directory to find the exact shard for user ID 12345.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Directory lookup returns shard for specific key [check]
Hint: Directory sharding uses centralized map to find shard [check]
Common Mistakes:
2. In a typeahead autocomplete system using a Trie, at step 3 the user input 'app' is processed. What does the Trie component do at this step?
easy
A. It hashes the prefix 'app' and looks up the prefix hash map for matches
B. It performs a full scan of all stored words to find matches starting with 'app'
C. It queries Elasticsearch to retrieve documents matching the prefix 'app'
D. It traverses the Trie nodes corresponding to 'a' -> 'p' -> 'p' to find all descendant words

Solution

  1. Step 1: Understand Trie traversal for prefix lookup

    The Trie component traverses nodes for each character in the prefix, here 'a' -> 'p' -> 'p', to reach the subtree containing all words starting with 'app'.

  2. Step 2: Eliminate other options

    Full scan is inefficient and not how Trie works; Elasticsearch and prefix hash map are separate components, not involved at this step.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Trie traversal follows prefix characters to subtree [check]
Hint: Trie lookup = follow prefix nodes step-by-step [check]
Common Mistakes:
3. A web application receives millions of HTTP requests per second and needs to distribute them evenly across multiple backend servers to avoid overload. Which component is primarily responsible for this task?
easy
A. A DNS server that resolves domain names to IP addresses
B. A caching proxy that stores frequently accessed responses
C. A load balancer that routes requests based on server health and capacity
D. A message queue that buffers incoming requests for asynchronous processing

Solution

  1. Step 1: Identify the component that distributes traffic

    A DNS server (A DNS server that resolves domain names to IP addresses) only resolves domain names and does not balance load dynamically. A caching proxy (A caching proxy that stores frequently accessed responses) serves cached content but does not distribute load evenly. A message queue (A message queue that buffers incoming requests for asynchronous processing) buffers requests asynchronously but does not route live HTTP requests to backend servers.

  2. Step 2: Understand load balancer role

    A load balancer (A load balancer that routes requests based on server health and capacity) routes incoming requests to backend servers based on health checks and capacity, preventing overload and ensuring even distribution.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Load balancer routes requests evenly based on server health [check]
Hint: Load balancer routes live traffic evenly [check]
Common Mistakes:
4. If the Key Management Service (KMS) becomes unavailable, what exactly breaks in the system's encryption-at-rest workflow?
medium
A. New encryption keys cannot be generated, but existing data remains accessible and decryptable
B. Data encryption stops, causing all writes to fail immediately
C. Decryption of existing data fails, causing read operations to block or error out
D. The system falls back to unencrypted storage, risking data exposure

Solution

  1. Step 1: Understand KMS role in key lifecycle

    KMS generates and manages encryption keys; if unavailable, new keys can't be created but existing keys cached locally allow decryption.

  2. Step 2: Eliminate incorrect failure modes

    Encryption doesn't stop immediately; decryption continues with cached keys; system does not fallback to unencrypted storage automatically.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    KMS outage blocks new key generation, existing keys still usable [check]
Hint: KMS down -> no new keys, existing keys still decrypt [check]
Common Mistakes:
5. At 10x scale of concurrent users, which component in a typeahead autocomplete system using Elasticsearch and Trie is most likely to become the bottleneck first, and why?
hard
A. The Trie servers, because in-memory Tries are stateful and cannot be easily sharded or distributed across nodes
B. The client-side UI, because rendering large autocomplete result sets slows down user experience
C. The prefix hash map, because storing all prefixes for billions of entries exceeds memory limits quickly
D. The Elasticsearch cluster, because fuzzy queries require heavy CPU and memory, causing query latency spikes

Solution

  1. Step 1: Analyze statefulness and scalability

    Trie servers hold large in-memory state and are difficult to shard due to pointer-based node structures, limiting horizontal scaling.

  2. Step 2: Compare other components

    Elasticsearch scales horizontally with shards; prefix hash map can be partitioned or replaced; client UI is less likely the first bottleneck at backend scale.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Trie statefulness limits sharding -> bottleneck at scale [check]
Hint: Trie stateful, hard to shard -> first bottleneck at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard