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.

What difficulty level is this interview question?

This is a medium difficulty System Design question, commonly asked during Technical Screen rounds at Chime.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Chime during technical interviews.

Design multi-tab browser history and trade-offs

Quick Overview

This question evaluates a candidate's competence in system design, data-structure selection, API specification, concurrency control, and eviction/semantic strategies for a multi-tab browser-history manager, testing skills in reasoning about per-tab state, operation complexity, and memory trade-offs.

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.

Quick Overview

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).

Design multi-tab browser history and trade-offs

Quick Overview

Design: Multi-Tab Browser History

APIs to Design

Functional Requirements

Design Discussion Requirements

Assumptions (refine as needed)

Solution

Comments (0)

Design multi-tab browser history and trade-offs

Quick Overview

Design: Multi-Tab Browser History

APIs to Design

Functional Requirements

Design Discussion Requirements

Assumptions (refine as needed)

Solution

Comments (0)