Design Browser History

Clarified whether the question is single-tab local history, multi-tab, or full multi-device sync, and scoped accordingly
Called out incognito/private mode as a explicit non-persistence requirement
Identified functional requirements: back/forward, visit recording, search, delete/clear
Identified non-functional targets: local latency (<10ms), sync latency, retention/storage scale

Proposed an in-memory data structure (two stacks or linked list) for O(1) local back/forward navigation
Included a local persistent store (SQLite/IndexedDB) separate from the in-memory navigation stack
Designed a sync layer (batching, cursor-based) between client and a backend History Service
Proposed a backend store partitioned/keyed by user with time-ordered sort key, appropriate for append-heavy writes

Explained branch truncation behavior (forward stack cleared on new navigation after back) and why
Addressed multi-device conflict/ordering strategy (e.g., last-writer-wins + tombstones vs full CRDT) with reasoning
Discussed sync scalability (incremental/cursor-based sync vs full resync) to avoid re-transferring entire history
Addressed storage growth/retention (TTL, partitioning, archiving) at scale
Explicitly handled incognito/private session isolation from persistence and sync as a correctness issue

Structured the interview using the time budget (requirements → high-level → deep dive → wrap-up)
Presented clear APIs and schema with justification for storage choice (NoSQL vs SQL)
Articulated trade-offs explicitly rather than presenting only one option
Gave a concise, confident opening/closing summary of the design

Problem