Design SoundCloud

Problem statement

Design SoundCloud: an open audio platform where any creator uploads a track, the platform processes it into streamable and scrubbable assets, listeners discover it through feeds, search, charts, and embeds, and the community interacts through the signature waveform and millisecond-anchored timed comments. The platform must host an open, unlicensed-by-default catalog, pay out creators, enforce rights, and survive viral spikes where a single unknown track goes from zero to millions of plays in hours.

This is not Spotify. A licensed streaming service receives clean, pre-mastered files from labels with negotiated rights and a closed catalog. SoundCloud's catalog is user-generated: arbitrary file formats, unknown quality, unknown rights, unknown intent. Therefore the ingest plane - upload, validation, transcoding, waveform extraction, loudness measurement, fingerprinting, rights screening - is the heart of the system, and it is asynchronous and eventually consistent. The delivery plane - playback start, seek, scrub, comment rendering - is the opposite: latency-critical, CDN-fronted, cache-obsessed. Conflating these two planes is the most common interview mistake.

Why the problem is distinctive

Four properties define the architecture. First, write-once-read-many with extreme skew: a track is processed once, then read anywhere from zero to tens of millions of times; the tail is enormous and the head is volcanic. Second, the waveform is both a visual identity and an interaction surface: comments attach to millisecond positions, scrubbing must feel instant, and comment density is overlaid on the peaks. Third, the open catalog means rights and moderation are continuous, adversarial, and legally consequential, not an afterthought. Fourth, the embed ecosystem means millions of playback sessions originate on third-party pages with different security and caching constraints.

Public operating baseline versus design assumptions

Public evidence shows the category is real. SoundCloud has company-reported figures of roughly 76 million monthly listeners and more than 30 million creators, with claims of 135+ million tracks on the platform; the company raised a widely reported $169.75M in August 2017 after a public funding crisis, took a widely reported $75M investment from SiriusXM in 2021, and launched its Fan-Powered Royalties model in April 2021. YouTube reports company-reported figures around 2 billion logged-in monthly users and roughly 500 hours of video uploaded per minute; Spotify reports company-reported scale in the hundreds of millions of monthly active users and publicly completed a Google Cloud migration. These are cited public figures for context.

For capacity planning, this answer explicitly assumes a mature platform with 80 million monthly actives, 8 million daily actives, 250,000 uploads per day, 2.5 billion play attempts per day, and a five-times event peak. Unless tied to a citation, every number here is a stated design assumption, budget, or target.

The four architectural planes

1. Ingest plane: resumable upload, validation, transcoding fan-out, waveform and loudness extraction, fingerprinting, rights screening, publish gating.
2. Delivery plane: CDN, manifest and segment serving, adaptive bitrate, seek, progressive fallback, embed player.
3. Social and discovery plane: timed comments, likes, reposts, playlists, follows, feed, search, charts, stations.
4. Governance plane: rights matching, takedowns, moderation, evidence, payout policy, audit.

A strong answer keeps the planes separate: ingest may be slow and retryable, delivery may never be slow, social must degrade without breaking playback, and governance must be able to veto publication without degrading delivery of already-published content.