# Design a Notebook App That Synchronizes Notes Design a web notebook application in which users can create and edit notes and automatically synchronize them through an external notes API. Focus on the client/server boundaries, the synchronization model, and behavior during failures or concurrent edits. You may state reasonable assumptions, but do not assume capabilities from the external API without calling them out. ### Constraints & Assumptions - Users expect edits to feel immediate even when synchronization is slow. - Network requests can time out, fail, or be delivered more than once. - A user may open the same note in multiple tabs or devices. - The design should avoid silently overwriting newer work. ### Clarifying Questions to Ask - Does the external API expose version identifiers, update timestamps, cursors, or idempotency keys? - Must editing work offline, or is a visible read-only/error state acceptable? - Which content types and note sizes are in scope? - Is collaboration between different users required, or only synchronization for one owner? ### Solving Hints Separate the local editing experience from the remote synchronization state. Identify the states a note can occupy and the evidence needed to decide whether an update is safe to apply. ### What a Strong Answer Covers - A clear data model for notes, local revisions, remote versions, and pending operations. - A synchronization loop with retries, idempotency, ordering, and bounded backoff. - Conflict detection and a user-safe resolution policy instead of last-write-wins by accident. - Authentication, authorization, secret handling, observability, and recovery from partial failure. - Explicit trade-offs between polling, push notifications, and API capabilities. ### Follow-up Questions - How would you prevent two browser tabs from repeatedly uploading the same change? - What changes if the external API has no version field or conditional-update operation? - How would you test synchronization races deterministically?