Spotify / Music Streaming — system design by AgileViper46

Availability target is named but not decomposed by critical user journey

You mention 99.9% availability for the system, but what happens when a shard primary fails, Kafka is delayed, or the search cluster is degraded? The explanation discusses some failover behavior, but it never defines which paths must meet 99.9% separately: streaming, search, playlist reads, uploads, and metadata writes have very different failure tolerance. You could improve this by stating per-path availability expectations and what graceful degradation is acceptable for each one.

Latency goals are qualitative, not measurable

You say 'low latency adaptive streaming' and 'low latency search,' but what happens if search takes 2 seconds or stream startup takes 5 seconds? Without concrete targets such as search p95/p99 latency or playback start latency, it is hard to judge whether the design actually meets the NFRs or where to spend complexity. You could improve this by defining measurable SLOs for startup time, chunk fetch latency, and search response time.

Scalability numbers do not fully connect to throughput assumptions

The design references 1B users, 100M DAU, and 10 songs/day, but what happens at peak traffic? Those assumptions imply very large daily and peak read throughput for streaming, metadata lookups, and search, yet the explanation does not translate them into request rates or peak concurrency to justify shard count, replica strategy, cache hit expectations, or search cluster sizing. You could improve this by converting the stated assumptions into peak QPS and using those numbers to defend the NFR choices.

Uploader/ownership relationship is left unclear

Have you considered how Song connects back to User for the upload flow? Users are allowed to upload music, but the entity model never makes explicit whether a song has an owner/uploader or how that relationship is represented. Without that link, it becomes hard to reason about permissions, attribution, and even basic queries like 'show me songs uploaded by this user.'

Playlist-to-song relationship is underspecified

Have you considered what happens when playlists contain many songs or the same song appears in many playlists? The design says a playlist 'has references' to songs, but it does not clearly define the relationship as many-to-many or how membership is modeled. At this scale, that relationship is a core part of the happy path and should be called out explicitly.

Searchable music metadata is not modeled as part of the domain

Have you considered which entity actually carries the searchable attributes required by the product, such as artist name and song name? Search is a functional requirement, but the core entity section only lists Song without clarifying whether artist/album-style metadata is part of Song or represented separately. Even if you keep Artist as embedded metadata rather than a standalone entity, that relationship should be made explicit so the search flow is grounded in the domain model.

Read QPS is underspecified for chunked streaming

Have you considered what happens when the chunking model is applied consistently to the peak calculation? You estimate 1B song plays/day, multiply by 10 for chunking, and get ~116K average read QPS, but the stated 500K peak appears to apply the 5x multiplier to song plays rather than chunk requests. If chunked delivery is the real unit of load, peak request volume is materially higher, and that affects CDN miss traffic, blob-store egress, and metadata lookups.

Major write-side capacities are missing

Have you considered what happens if uploads, playlist mutations, and search indexing spike? The design includes user uploads, transcoding, CDC, Kafka, playlist creation, and search sync, but there are no write QPS or ingestion-volume estimates to show whether those pipelines are sized appropriately. At senior level, I would expect at least rough sizing for upload throughput and background processing because those can dominate internal capacity even if end-user reads are CDN-heavy.

Storage growth is only calculated for source audio

Have you considered what happens to storage once transcoding creates multiple bitrate renditions and offline-download variants? The 5PB raw estimate appears to count one 5MB object per song, but the explanation explicitly stores multiple encoded outputs and chunks. That can multiply object count and total bytes significantly, so the current storage number likely understates blob capacity and replication needs.

No bandwidth or egress sizing for streaming workload

Have you considered what happens to network capacity at peak playback? For a music system, request QPS alone is not enough; bitrate drives CDN and blob egress. Without a rough estimate of average stream bitrate, cache hit rate, and resulting backend egress, it is hard to tell whether the proposed CDN/blob architecture actually fits the stated 100M DAU scale.

Playlist APIs do not fully support the stated create/share flow

Have you considered how a client updates playlist contents or metadata after creation? Right now there is POST, GET, and DELETE, but no clear update route such as PATCH /playlists/{id} or song-level add/remove operations. Without that, playlist management is incomplete for a real user flow.

Upload flow is missing the completion/finalization API described in the explanation

What happens after the client uploads the file to the presigned URL? In your walkthrough, the song moves through states like created, uploaded, and encoded, but the route list has no finalize/complete endpoint or status endpoint. Without that, the client does not know how to tell the system the upload finished or how to poll until the song is ready to stream.

Streaming protocol is only partially specified

Have you considered how the client discovers the manifest/master playlist before requesting chunks? The explanation talks about requesting a master file and then adaptive bitrate chunks, but the API list only shows GET /songs/{songId}/{variant}/{chunkId}. Without a manifest endpoint or a clear contract on how variant and chunk IDs are discovered, the streaming flow is underspecified.

Resource design mixes storage details into public URLs

What happens if your chunking scheme or variant naming changes? Exposing /songs/{songId}/{variant}/{chunkId} tightly couples clients to internal media layout. A cleaner contract would return a manifest or signed media URLs so the server can evolve chunk structure without breaking clients.

HTTP method and route semantics are inconsistent

Have you considered the semantics of PUT /preSignedUrl and GET /songs/:id/download? PUT /preSignedUrl is not really updating a presigned-url resource; it appears to upload media bytes to object storage. Similarly, GET /songs/{id}/download likely needs to return a redirect or signed URL rather than the file itself. The current route naming makes it unclear what the client should actually send and receive.

Error handling and retry behavior are not defined

What does the client see when search is rate limited, a presigned URL expires, an upload part fails midway, or a song is not yet encoded? Without status codes, error shapes, and retry guidance, clients cannot reliably recover from common failures. At this level, I would expect at least a consistent error contract and explicit handling for transient vs terminal failures.

Primary database is still a major bottleneck in the current diagram

You mention sharding in the explanation, but the diagram still shows a single Postgres cluster serving song metadata, playlist metadata, CDC, and replication. At 1B songs and large playlist traffic, what happens when that single logical cluster becomes the coordination bottleneck for writes, failover, and CDC fan-out? The design would be stronger if the sharded metadata layer were made explicit, including how Song Service and Playlist Service route to shards.

Playlist and song metadata are mixed into one storage path without clear partitioning

Have you considered what happens when playlist growth and song catalog growth stress the same Postgres cluster differently? Public playlists can become very hot and have very different access patterns from song metadata. Without a clear separation of tables/services/shards for songs versus playlists, one workload can interfere with the other.

Read path for metadata is not fully traced end-to-end

The design shows Song Service and Playlist Service writing to Redis, but it does not show how reads use Redis first and fall back to the database. What happens on a cache miss for GET /songs/{id} or GET /playlists/{id}? The system likely works, but the hot metadata read path is underspecified in the HLD, which matters at this scale.

Offline download and streaming share the same asset path without any control point

You reuse the CDN path for offline download, which is directionally fine, but what happens when large download bursts compete with interactive streaming traffic for the same cached objects and origin bandwidth? Without a separate policy or traffic shaping layer, download-heavy behavior can degrade the low-latency streaming requirement.

Failure handling around encoding completion is thin

What happens when encoding succeeds for some variants but the completion event to Song Service is delayed or lost? The song could exist in blob storage but remain unavailable or partially available from the metadata perspective. The design would benefit from a clearer source of truth for asset readiness and idempotent completion handling.

Single points of failure are not fully addressed for critical control-plane services

You discuss DB replica failover, but what happens if Song Service, Playlist Service, Search Service, Redis, or Kafka has a node failure or partition? The HLD implies clustered components in some places, but the HA story is only explicit for Postgres. At 99.9% availability, the control plane should not depend on a single instance of these services.