Spotify System Design Architecture Simulator & Capacity Planner

Architecture Scenario

Registered Users 50,000,000

Catalog Song Count 200,000,000

Audio Size (Ogg/AAC avg) 3.0 MB

CDN Edge Cache Hit Ratio 85%

Capacity Math Verification

Audio Blob Storage

600 TB

Song Metadata (100B/song)

20 GB

User Metadata (1KB/user)

50 GB

Est. Stream QPS (Peak)

11,574 /s

Live Traffic Injection

Ready for request simulation 0 ms

Click "Play Song" or "Upload Song" to trace packet routing across CDN, Load Balancer, Web APIs, SQL Leader/Followers, and Blob Storage.

Topology: End-to-End Streaming & Metadata System Design Scaled Architecture (CDN Active, Leader-Follower DB)

Relational SQL Schema (PostgreSQL/MySQL)

Users

UserID (PK)BIGINT

UsernameVARCHAR(50)

EmailVARCHAR(100)

PasswordHashCHAR(60)

CreatedAtTIMESTAMP

Songs

SongID (PK)BIGINT

TitleVARCHAR(255)

ArtistID (FK)BIGINT

DurationSecINT

FileURL (Blob)VARCHAR(512)

Artists

ArtistID (PK)BIGINT

NameVARCHAR(100)

BioTEXT

CountryCHAR(2)

ArtistsSongs (Junction)

ArtistID (FK)BIGINT

SongID (FK)BIGINT

RoleVARCHAR(30)

PRIMARY KEY (Artist, Song)

Architecture Trade-offs & Principles

1. Storage Bifurcation: Audio files are immutable binary objects stored in AWS S3 or GCP Cloud Storage. Relational metadata is stored in SQL tables to allow multi-artist joins, user playlists, and exact search. The SQL table stores only the FileURL pointer.

2. Read-Heavy Scalability: Spotify traffic exceeds 99% reads. In the Scaled Phase, write operations (song uploads, profile edits) target the single SQL Leader, while queries are load-balanced across multiple Read Followers.

3. LRU Edge Caching: Streaming 200M songs directly from origin blob storage is cost and latency prohibitive. Edge CDNs cache popular songs (top 20% songs drive 80% of streams) with an LRU eviction policy, serving cache hits in <20ms.