How the interviewer opens it
“Design a file storage and sync service like Dropbox or Google Drive. Users should be able to upload files, keep them in sync across devices, and share them with other people.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- users and stored data
- traffic and read:write mix
- file sizes and operations
- offline behavior and conflicts
- latency
- consistency and availability
- durability and retention
- ownership, sharing, and moves
- revocation
- scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Upload and download files, including interrupted transfers
- Create, rename, move, and delete files and folders within the content owner's tree, including moves into and out of shared folders
- Sync changes across devices, including devices returning after time offline
- Share existing files and folders with named users as viewers or editors
Usually out of scope
- Real-time document co-editing
- Full-text search and document previews
- Public sharing links and complex permission overrides
- Ownership transfer and identity-preserving moves between different owners' trees
- Building the underlying object storage service
- Global cross-user deduplication
What interviewers probe
- Resumable upload and atomic version publication
- A 20 GB transfer can fail repeatedly, while object storage and the metadata database do not share a transaction. A successful commit must expose exactly one complete version without retries creating extra versions.
- Offline conflicts, renames, and deletions
- Devices operate on stale views, paths change, and a deleted or no-longer-shared file may still have unsynced edits elsewhere. Correctness means preserving user work, not merely converging to one timestamp winner.
- Fast change discovery without losing changes
- The service needs near-immediate updates without constant polling. Notifications can be lost, owner-log events can reach projections more than once, and a shared view can have thousands of devices catching up.
- Ownership boundaries, shared subtrees, and revocation
- Sharing an existing folder must not silently change its storage owner. Moving a subtree changes inherited access and multiple clients' views, while recipient indexes, feeds, and byte capabilities live outside the metadata transaction.
Common mistakes
- Designing only a blob upload service and leaving out device reconciliation.
- Treating push notifications as a reliable log or repeatedly listing the entire tree.
- Using paths and client timestamps as identity and conflict resolution, causing rename duplication or lost offline edits.
- Assuming object uploads and metadata publication share a transaction, or making commit retries create extra versions.
- Conflating share scopes with ownership partitions and leaving existing-subtree sharing, moves, and feed transitions undefined.
- Treating permanent object URLs or cached mount membership as authorization and ignoring bounded revocation.
The bar by level
- Senior (L5/E5)
- Defines durable-content-before-publication, retry-safe commits, base-version checks, replayable cursors, tombstones, and old-client reconciliation. Separates owner placement from sharing views, handles supported moves across sharing boundaries with explicit visibility events, and enforces bounded revocation at download authorization and upload commit.
- Staff (L6+/E6+)
- States invariants across owner metadata, content storage, derived feeds, devices, and authorization, then tests them against failures. Handles commit ordering, projection replay, subtree snapshot handoffs, overlapping views, permission races, and reclamation. Identifies the limits of one-owner transaction domains and gives an explicit protocol when cross-owner moves or regional write availability are introduced, rather than assuming a wider transaction.