Question 1

How do you implement document version history with storage efficiency?

Accepted Answer

Two strategies: full-content storage vs delta storage. Full content: each version stores the complete document content in S3. Pros: O(1) version access (just fetch the S3 object). Cons: storage grows linearly with version count. A 1MB document with 100 versions = 100MB. Use content-hashing for deduplication: if two versions have identical content (SHA-256 hash), they point to the same S3 object. Deduplication saves storage when users save without making changes. Delta storage: store only the diff from the previous version (unified diff format for text). Pros: 80-90% storage reduction for text documents. Cons: accessing version N requires applying N diffs sequentially. Mitigation: store full snapshots every 20 versions, then apply at most 19 diffs. Binary files (PDFs, images): always full-content (diffs are not human-readable and rarely compress well).

Question 2

How does hierarchical permission inheritance work in a document system?

Accepted Answer

Permissions cascade from workspace -> folder -> document. Resolution: find the most specific permission for a user on a document. Check document-level permissions first. If not found: check folder permissions. If not found: check workspace default. This is 'most specific wins' inheritance. Group membership: a user can belong to multiple groups. Their effective permission = maximum across (all group permissions + individual permission) at the most specific level. Algorithm: get_effective_permission(user_id, doc_id): check doc permissions for (user_id, all user groups). If found: return max. Check parent folder. If found: return max. Check workspace default. Return max. Caching: resolve and cache user:doc -> permission in Redis (TTL 5 min). Invalidation: on any permission change (doc, folder, workspace, or group membership), invalidate all cached permissions for affected documents and users.

Question 3

How do you implement full-text search across documents with access control?

Accepted Answer

Challenge: search results must respect permissions -- users should not see documents they cannot access. Options: (1) Post-filter: run the search, then filter results by permission check. Simple but inefficient -- if top 100 results are all restricted, you return nothing and must fetch more. (2) Pre-computed ACL in index: store the list of authorized user/group IDs on each document in Elasticsearch. At query time, filter by: must match the search query AND (user_id IN authorized_users OR any_user_group IN authorized_groups). Efficient but requires re-indexing when permissions change. (3) Permission-scoped shards: shard the index by workspace, and apply workspace-level access control at the shard level. Simple for single-tenant systems. Production systems use option 2 with careful indexing: when a document's permissions change, update the authorized_users field in Elasticsearch (partial update).

Question 4

How do you implement real-time collaborative editing?

Accepted Answer

Real-time collaboration means multiple users editing the same document simultaneously and seeing each other's changes instantly. Architecture: WebSocket connection from each client to a collaboration server for the document. When a user makes an edit: encode it as an operation (insert, delete, retain). Send to collaboration server. Server broadcasts to all other clients. Conflict resolution: two users insert at the same position simultaneously. Operational Transformation (OT) -- the algorithm used by Google Docs -- transforms concurrent operations to produce a consistent result. Each operation is transformed against all concurrent operations before being applied. Implementation: use ShareDB (OT) or Yjs (CRDT -- Conflict-free Replicated Data Types, used by Notion). CRDTs are simpler to reason about: each character has a globally unique ID, concurrent inserts are deterministically ordered. For most interview purposes: describe the WebSocket + OT/CRDT architecture without implementing OT.

Question 5

How would you design document sharing with time-limited public links?

Accepted Answer

Share links allow document access without requiring an account. ShareLink entity: (link_id, doc_id, token, permission_level=VIEWER|COMMENTER, expires_at, created_by, is_active, access_count). Token generation: cryptographically secure random token (128 bits, URL-safe base64 encoding = 22 characters). Expiry options: never, 1 day, 7 days, 30 days, custom. Access flow: user visits /share/{token}. Server looks up the ShareLink by token. Checks is_active=true and expires_at > NOW(). Serves the document at the link's permission level. No authentication required. Tracking: increment access_count on each visit. Log accesses (IP, user-agent, timestamp) for the document owner's analytics. Revocation: set is_active=false immediately invalidates the link (even if not expired). Security: tokens must be unguessable (128-bit entropy). Never expose doc_id in the share URL -- token alone identifies the document.

Low-Level Design: Document Management System — Versioning, Permissions, Full-text Search, and Collaboration

Core Entities

Versioning and Storage

Permission Model

Full-text Search

Real-time Collaboration

Interview Tips