Design multi-tab browser history and trade-offs

Q: Design multi-tab browser history and trade-offs

This is a System Design interview question from Chime for Software Engineer roles. View the full question and solution on PracHub.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Question

Design: Multi-Tab Browser History

Context: Extend a single-tab browser-history component into a multi-tab manager that supports opening/closing tabs, switching the active tab, and performing visit/back/forward on the active tab.

APIs to Design

int openTab(string homepage)
void closeTab(int tabId)
void switchTab(int tabId)
void visit(string url)
string back(int steps)
string forward(int steps)
Optional: bool haveVisited(string url) — define per-tab and/or global semantics

Functional Requirements

Each tab maintains its own navigational history (back/current/forward).
visit(url) clears the forward history of the active tab and navigates to url.
back(steps) and forward(steps) move within the active tab, clamped by available steps, and return the current URL.
openTab returns a stable, unique tab identifier; switchTab changes which tab is considered active.
closeTab disposes of the tab’s history.

Design Discussion Requirements

Data structures for:
- Per-tab history.
- Registry of open tabs and (optionally) their order (e.g., MRU).
Compare trade-offs (e.g., map vs. list) including memory footprint and operation complexity.
Complexity targets and justification per operation.
Thread-safety if multiple tabs can act concurrently: propose locking/immutability.
History capping/eviction policies and how they affect haveVisited semantics (per-tab and/or global).

Assumptions (refine as needed)

Up to N tabs (e.g., 1e5). Each tab’s history can be capped at H entries.
Active tab is maintained per Browser instance/session.
URLs are arbitrary strings.