Design SoundCloud

Problem Statement & Context

SoundCloud is a creator-first audio platform: anyone can upload a track, and within seconds it is transcoded into a streaming ladder, given a visual waveform, and made shareable to a social graph of followers. The features sound simple — upload, stream, follow, repost, comment — but two properties make the design interesting. First, it is user-generated audio, so like YouTube it has a brutal read/write asymmetry (far more plays than uploads) and an unbounded, ever-growing catalog. Second, it is fundamentally social: discovery happens through The Stream — a reverse-chronological feed of uploads and reposts from the creators you follow — so the design is part media platform and part social network.

It helps to see SoundCloud as three coupled systems. A media pipeline ingests an upload, transcodes it to multiple bitrates, generates waveform peaks, and stores everything in object storage. A social graph captures follows, reposts, likes, and timestamped comments anchored to a position on the waveform. And a discovery layer — The Stream plus search and recommendations — turns the catalog and the graph into something a listener actually opens. The interesting trade-offs live where these meet: a creator with millions of followers makes feed fan-out expensive, while audio's small files make storage and bandwidth far cheaper than video.

Audio changes the economics relative to video. A 3-minute track at 128 kbps is roughly 3 MB, so the catalog and egress are one to two orders of magnitude smaller than a video platform's — which means the hard problems shift away from raw bandwidth and toward the social fan-out, the waveform/timestamped-comment experience, and accurate play-count accounting at viral scale. The interviewer wants you to recognize that this is YouTube's read-heavy ingest problem fused with Twitter's feed fan-out problem, on cheaper (audio) bytes.