## Design an Offline Multi-Device E-Book Reader Design an e-book reader service with APIs, database schema, and overall architecture. A user may read offline and use several devices for the same book. The system must synchronize reading progress without letting stale devices blindly overwrite newer progress. ### Part 1 — Define the Customer and Data Contract Specify library, book-content, device, reading-session, annotation if in scope, and progress APIs and records. Define what one progress position means across different renderings. #### What This Part Should Cover - Stable account, device, book edition, content version, and progress identities. - A canonical locator more durable than a device-specific page number. - Idempotent download and progress-update requests. - Clarified behavior for loans, purchases, annotations, and content revisions. ```hint Do not synchronize a screen number Font size and device dimensions change pages, so progress needs a content-relative locator that devices can translate locally. ``` ### Part 2 — Support Offline Reading and Sync Design download manifests, local state, an offline operation log, reconnect behavior, retries, and bandwidth-efficient synchronization. #### What This Part Should Cover - Versioned content chunks with integrity and entitlement checks. - Local progress plus a durable pending-operation queue. - Server acknowledgement and safe retry by operation ID. - Reauthorization and deletion behavior when entitlement changes. ```hint Queue intent, not only the latest HTTP call Offline progress must survive application restart and reconnect without depending on one request remaining open. ``` ### Part 3 — Resolve Multi-Device Progress Conflicts Define the merge policy when two devices read the same book offline and later report different positions. Explain how users can intentionally reread an earlier section without the system always forcing the furthest position. #### What This Part Should Cover - Device sequence, base version, event time, and server receipt time. - A distinction between automatic forward progress and an explicit user-set position. - Conditional writes, conflict responses, or merge records rather than last-write-wins by arrival alone. - Customer-visible recovery from ambiguous conflicts. ```hint Preserve why the position changed “Reached chapter ten” and “explicitly moved back to chapter three” should not be merged as indistinguishable scalar numbers. ``` ### Part 4 — Serve, Cache, and Operate Reliably Design authoritative stores, content delivery, progress reads and writes, caching, consistency, reconciliation, privacy, and metrics. #### What This Part Should Cover - Object storage or CDN for content and a transactional store for entitlements and progress. - Read-your-writes for the active device with defined cross-device convergence. - Version-aware caches and no caching of unauthorized content. - Sync lag, conflicts, stale updates, failed downloads, and reconciliation metrics. ```hint Match consistency to the experience Book bytes can be immutable and heavily cached, while a progress update is small, user-specific, and sensitive to write conflicts. ``` ### What a Strong Answer Covers - Centers offline continuity and understandable conflict outcomes. - Uses stable content locators and versioned idempotent sync. - Prevents stale-device overwrite without making intentional rereading impossible. - Separates content distribution, entitlement, and progress consistency. ### Follow-up Questions 1. What happens when an edition changes while a device is offline? 2. How would annotations be merged differently from one progress cursor? 3. Which data must be deleted when a loan expires? 4. How would you test two devices reconnecting in opposite orders?