Design an Audiobook Streaming Service

Problem statement

Design an audiobook streaming service where users browse a large catalog, stream or download titles organized into chapters, pause and resume from the exact second on any device, bookmark and highlight passages, optionally follow a synced text transcript, adjust playback speed, and receive recommendations.

Audiobooks occupy a distinct corner of media system design. A song is 3 minutes and is usually consumed whole. A video is 45 minutes with visual keyframes. An audiobook is 10 to 40 hours of narration, consumed across days or weeks in fragments, almost always resumed mid-chapter, frequently shifted between phone, car, and smart speaker. The session is not the listen; the position is the product. Lose the resume point and the user abandons the service, no matter how good the catalog is.

Three properties dominate the architecture. First, chapter structure is a first-class object: chapters drive seeking, sleep timers, navigation, and the consumption contract with publishers. Second, cross-device position synchronization must converge within about a second even when device clocks disagree and networks partition. Third, the catalog is enormous per title: a 20-hour book is roughly 1 GB at 96 kbps AAC, so a serious library reaches petabyte-scale origin storage behind a CDN.

Public operating baseline

The category is operationally real. Audible publicly reports a catalog of more than 1,000,000 titles. Storytel reported 2.3 million subscribers in its Q4 2023 report and a catalog above 200,000 titles. Spotify opened audiobooks to US Premium users in September 2023 with a 15-hour monthly listening cap and later expanded to the UK and Australia. These are cited company figures for context, not requirements of our fictional system.

For capacity planning this answer explicitly assumes a mature service with 10,000,000 monthly active users, 2,500,000 daily active users, about 4,200,000 listening sessions per day, and a peak of roughly 450,000 concurrent listeners. Unless tied to a citation, every number here is a stated design assumption.

The four architectural planes

1. Content plane: ingestion, chapter segmentation, loudness normalization, transcoding, packaging, and catalog publication.
2. Delivery plane: origin storage, CDN distribution, range or segment requests, offline packages, and DRM license flows.
3. Listener plane: catalog APIs, playback state, position and speed sync, bookmarks, highlights, transcript alignment, and recommendations.
4. Platform plane: identity, entitlements, subscriptions, analytics, experimentation, and cost governance.

A strong interview answer keeps these planes separate. The delivery plane can degrade to a regional CDN failover without corrupting the listener plane's position ledger, and the content plane can re-encode a title without touching any live playback session.