Design a Book Store with E-Book Delivery

Problem Statement

Design a book store platform that sells e-books to readers worldwide. The system must handle catalog browsing, purchase and entitlement, secure file delivery with DRM, cross-device reading progress sync, and territory-based licensing compliance. Readers buy a book once and expect it available in their library on every device—phone, tablet, e-reader, and web—without re-purchasing.

This is not a physical-commerce problem. There is no warehouse, no shipping carrier, no inventory count of physical units. The "product" is an immutable digital file (EPUB, PDF, or proprietary format) protected by encryption and licensing rules. The hard problems shift from logistics to content distribution at scale, cryptographic key management, territory-based copyright enforcement, and state synchronization across devices.

Why this problem is distinctive

A physical book store designs around inventory management, order fulfilment pipelines, and carrier integrations. An e-book store designs around:

1. Immutable content distribution. Book files are written once and read millions of times. The dominant cost is egress bandwidth, not storage. A CDN is not optional—it is the primary delivery mechanism.

1. Cryptographic entitlement. A purchased e-book is not a plaintext file the user can freely copy. DRM (Digital Rights Management) encrypts the content and binds decryption keys to the purchaser's account and authorized devices. The license server becomes a critical-path dependency.

1. Territory and copyright law. A publisher may grant distribution rights in the US but not in Germany. The platform must enforce geo-restrictions at the point of sale and at the point of download, not as an afterthought.

1. Cross-device state sync. A reader who finishes chapter 3 on their phone at midnight expects to open chapter 3 on their tablet the next morning. Reading position, bookmarks, highlights, and annotations must propagate across devices with conflict resolution for offline edits.

1. Long-tail catalog economics. A store with 6 million titles (comparable to the Kindle Store) has a power-law demand distribution: the top 1,000 titles generate the majority of traffic, while millions of backlist titles sell a few copies per year. The architecture must serve hot titles from edge caches and cold titles from origin storage without proportional cost scaling.

Public operating baseline versus design assumptions

Amazon's Kindle ecosystem, launched in 2007, reports over 6 million titles in the Kindle Store and Whispersync technology that synchronizes reading position across devices. Kobo (owned by Rakuten) operates in 190+ countries with approximately 40 million registered users. Apple Books is pre-installed on over 1 billion active iOS devices. These are public figures that establish the category is operationally real at massive scale.

For capacity planning, this answer explicitly assumes a mature platform with 50 million registered users, 8 million monthly active users, 2 million daily active users, 500,000 purchases per day, and 10 million file downloads per day. Unless a number is tied to a public citation, it is a stated design assumption.

The four architectural planes

1. Commerce plane: catalog, search, purchase, payment, entitlement ledger, refunds.
2. Content delivery plane: file storage, encryption, DRM license issuance, CDN distribution, signed-URL generation, download resume.
3. Reading experience plane: progress sync, bookmarks, highlights, annotations, offline library management.
4. Governance plane: territory rights, copyright compliance, publisher contracts, anti-piracy monitoring, audit.

A strong interview answer keeps these planes separate. The commerce plane must not block on the content delivery plane for a purchase confirmation. The reading experience plane must tolerate CDN outages by falling back to locally cached content. The governance plane must be able to revoke a title's availability in a territory without affecting already-purchased entitlements.