Design a browser sync service

How the interviewer opens it

“Design a service that keeps bookmarks, browser history, settings, and open tabs in sync across a user's devices. Devices can remain offline for long periods.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

• Scale
• Read and write mix
• Data size
• Retention and device contact
• Offline devices
• Latency
• Consistency and availability
• Durability
• Data and conflict rules
• Security and exclusions

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

What interviewers ask about

Concurrent bookmark edits

Devices can edit different fields or change the folder tree without seeing each other. Whole-record replacement can lose valid edits.

Devices that return after a long absence

The service cannot retain every deletion forever. An old device can mistake deleted data for new data after the service removes deletion records.

Sync progress and retries

A device must track complete progress despite retries, partial responses, concurrent writes, and crashes. An incorrect cursor can skip changes permanently.

History and device tabs

Visits expire by age, but bookmarks do not. Other devices must learn when unchanged tabs disappear or return.

Common mistakes

• Replace whole collections and lose unrelated concurrent edits.
• Trust device clocks to define the order of all changes.
• Remove deletion records without a rule for old devices.
• Replay an expired outbox and restore deleted items.
• Expire history only on the server, or accept visits that already exceed 90 days.
• Keep device metadata only in snapshots, so incremental clients miss tab visibility changes.

The bar by level

Senior (L5/E5)

Defines atomic server writes and client progress. Handles snapshots, folder cycles, history expiry, stale baselines, and unsent edits. Sends device visibility changes through incremental sync. Requires durable replication before acknowledgment.

Staff (L6+/E6+)

Explains the limits of finite retention after an unlimited absence. Resolves ambiguous old requests safely. Handles device contact costs, visibility races, and notification loops. Defines failover authority, regional recovery, and refresh load controls.