Design Google Drive (LLD)
Files, folders, sharing/permissions, and search — a hierarchical storage model with ACLs.
Problem Statement
Design the object model for Google Drive at an LLD level: users create files and folders, organize them as a tree, share items with viewer/commenter/editor permissions, version file content, search accessible items, star important items, and move items to trash.
The important interview axis is not storage blocks or global scale. It is the permission model: every read, comment, edit, share, and trash operation must pass through a Proxy/authorization layer that resolves inherited folder permissions before touching the Composite file tree.
Business context
Google Drive is a strong expert-level LLD problem because it combines a familiar product surface with subtle ownership and sharing rules. Most candidates model the file/folder tree quickly; stronger candidates separate tree behavior from authorization, avoid scattering if user can edit checks across services, and explain how inherited ACLs interact with direct file shares. The design below keeps the hierarchy simple and puts access decisions behind AccessProxy, making permission correctness the center of the solution.
Functional Requirements
Create folders and files under an existing folder using a Composite tree.
Read file contents only when the caller has at least VIEWER access through direct or inherited permission.
Add comments only when the caller has at least COMMENTER access.
Edit file contents, restore versions, create children, share items, and trash items only when the caller has EDITOR access.
Support direct sharing at any file or folder with permission levels VIEWER, COMMENTER, and EDITOR.
Inherit folder permissions down to descendants unless a descendant has a direct permission for that user.
Maintain file version history every time content changes and allow restoring an older version as a new current version.
Search by pluggable strategy over only visible, non-trashed items; support starred and trashed state.
Non-Functional Requirements
Permission correctness
Every public operation must delegate to AccessProxy before reading or mutating an item. A missed check is a product-severity bug, not a minor edge case.
Extensible authorization
Permission resolution should support direct ACLs today and inherited folder ACLs tomorrow without rewriting DriveService flows.
Tree integrity
A folder owns unique child names, each child has one parent, and moving or deleting should preserve a valid Composite structure.
Search isolation
Search policy should vary independently of traversal. Name search, text search, owner search, or metadata search should be strategies.
Auditability
Version changes, shares, stars, and trash operations should be observable so a production system can emit activity feed and audit events.
Requirement Clarification
QDo we need to model actual blob storage, chunking, or sync clients?
No. This is the LLD view of Drive objects and permissions. Blob storage, sync conflict resolution, and offline clients are production extensions or a Dropbox-style follow-up.
QWhich permission levels are required?
Use exactly VIEWER, COMMENTER, and EDITOR. Treat the owner as having effective editor access even if no ACL row is present.
QDo folder permissions apply to files inside the folder?
Yes. AccessProxy walks from the target item toward ancestors and uses the nearest direct permission it finds; owners are granted effective editor access.
QIs starring global or per user?
The interview implementation stores a simple starred flag on the item to keep focus on permissions. In production it should be per-user metadata.
QWhat does trash mean in the base design?
Trashed items remain in the tree but are hidden from normal search and visible-tree output. A permanent purge can be added as a follow-up policy.
UML Class Diagram
Sequence Diagram
Entity Identification
DriveService
Application facade. Resolves ids, calls AccessProxy for every operation, mutates the Composite only after authorization, runs search strategies, and notifies observers.
AccessProxy
Authorization boundary. Computes effective permission from owner, direct ACL, or inherited ancestor ACL, then allows or rejects a requested action.
DriveItem
Abstract Component in the Composite. Owns identity, owner, parent link, starred/trash flags, direct permissions, path calculation, and the common operations files and folders implement.
FileItem
Leaf node. Stores content versions, comments, read/update behavior, and searchable text for the file body and comments.
FolderItem
Composite node. Owns uniquely named child DriveItem objects, supports recursive id lookup, and aggregates descendant size.
Permission
Ordered enum for VIEWER, COMMENTER, and EDITOR. The allows method expresses that editor includes commenter and viewer rights.
VersionHistory
Append-only version list. Each content update creates a new version id; restoring an old version appends it as the latest version for auditability.
SearchStrategy
Pluggable predicate used by DriveService.search after authorization filtering. It keeps name search and content search out of the traversal code.
DriveObserver
Notification seam for activity feed, audit log, and indexing. Observers receive events after successful mutations.
Design Patterns Used
DriveItem is the shared component, FileItem is the leaf, and FolderItem is the composite. The service can search, size, and display a subtree through one abstraction.
AccessProxy protects the real objects. It resolves effective permission from owner, direct share, or inherited folder share before the service reads or mutates an item.
SearchStrategy lets the traversal stay fixed while matching behavior changes: by name, by content, by owner, by metadata, or by future ranking logic.
DriveObserver subscribers are notified after version, share, star, and trash changes. This models activity feeds, audit trails, and async search indexing without coupling them to core mutations.
Step-by-Step Design
1Model permission levels as an ordered enum
Viewer, commenter, and editor form a capability ladder. Put that ladder in Permission.allows so authorization never relies on scattered ordinal checks or string comparisons.
public enum Permission { VIEWER, COMMENTER, EDITOR; public boolean allows(Permission required) { return ordinal() >= required.ordinal(); } }2Build the file tree as a Composite
Keep identity, owner, ACL, path, starred, and trash state in DriveItem. Files and folders implement size and searchText differently while remaining one tree type.
public abstract class DriveItem { public abstract boolean isFolder(); public abstract long size(); public abstract String searchText(); }3Make the Proxy the only permission decision maker
The service never asks raw ACL maps. It calls AccessProxy.require with the action and required permission, and the proxy walks ancestors for inherited access.
public void require(String userId, DriveItem item, Permission required, String action) { Permission actual = effectivePermission(userId, item); if (actual == null || !actual.allows(required)) { throw new SecurityException(userId + " cannot " + action + " " + item.getPath()); } }4Keep versioning inside the file leaf
A folder should not know how file content changes. FileItem.updateContent appends to VersionHistory, and restore is just another version append for an auditable timeline.
public void updateContent(String newContent) { versionHistory.addVersion(newContent == null ? "" : newContent); }5Filter before matching in search
Search traversal visits the tree, but each candidate is checked with AccessProxy.canView and ignored if trashed before the SearchStrategy runs. A user never discovers private names through search.
6Publish domain events after successful mutations
Observers are called only after authorization and mutation succeed. That ordering keeps audit logs and search indexes consistent with the authoritative tree.
Complete Java Implementation
Explanation of Every Class
DriveItem
The abstract Component. It owns shared identity, owner, parent, starred/trash flags, direct ACL map, path calculation, and the common polymorphic methods that files and folders implement.
FileItem
The leaf node. It delegates content snapshots to VersionHistory, stores comments, exposes read/update/restore operations, reports size from current content, and contributes content plus comments to search text.
FolderItem
The Composite node. It owns a deterministic child map, rejects duplicate names, wires parent links, finds descendants recursively by id, and aggregates visible descendant size.
Permission
The ordered permission ladder. EDITOR allows edit, comment, and view; COMMENTER allows comment and view; VIEWER allows only read/search visibility.
AccessProxy
The authorization Proxy and most important class in the design. It resolves owner, direct permission, and inherited folder permission before approving or rejecting each action.
VersionHistory
Append-only file version log. Each write adds a version id with content and timestamp; restoring an older version appends a fresh current version rather than mutating history.
DriveService
The application facade. It resolves ids, asks AccessProxy before every public operation, updates files/folders only after authorization, runs SearchStrategy, and publishes DriveObserver events.
Main
A compact demo that creates a folder and file, shares a folder as commenter, shows a denied edit, upgrades a file to editor access, versions it, stars it, and searches visible content.
Dry Run
Sample input
Alice owns My Drive. Actions: create Specs/api-design.txt, share Specs with Bob as COMMENTER, Bob reads and comments, Bob tries to edit, Alice shares the file with Bob as EDITOR, Bob edits, stars, and searches for permissions.
| Step | Operation | Proxy decision | State change | Result |
|---|---|---|---|---|
| 1 | Alice creates Specs folder | Alice is root owner so EDITOR | Folder added under My Drive | Specs id returned |
| 2 | Alice creates api-design.txt | Alice is Specs owner so EDITOR | File leaf added with version v1 | File id returned |
| 3 | Alice shares Specs with Bob COMMENTER | Alice has EDITOR on Specs | ACL on Specs grants Bob COMMENTER | Inherited access begins |
| 4 | Bob reads file | File has no direct ACL, parent Specs grants COMMENTER | No mutation | Read succeeds |
| 5 | Bob comments | COMMENTER satisfies comment requirement | Comment appended | Observer event emitted |
| 6 | Bob edits | COMMENTER does not satisfy EDITOR | No content change | SecurityException |
| 7 | Alice shares file with Bob EDITOR | Alice has EDITOR | Direct file ACL grants Bob EDITOR | Direct permission overrides need for folder edit |
| 8 | Bob edits and searches | EDITOR satisfies edit; VIEWER satisfies search | Version v2 added, item starred | Search returns visible file |
The key transition is Step 6 to Step 7. Bob can read and comment through inherited folder access, but the Proxy blocks editing until the file receives direct EDITOR permission.
Complexity Analysis
| Operation | Time | Space | Note |
|---|---|---|---|
| create file or folder | O(N) | O(1) | The service resolves the parent by recursive id lookup over N items, then inserts one child. |
| permission check | O(H) | O(1) | The Proxy walks from target to root over height H until it finds owner or direct permission. |
| read or comment | O(H) | O(1) | Authorization dominates; reading current content and appending a comment are constant in this model. |
| update file / restore version | O(H + V) | O(C) | Update is O(H) plus storing content C. Restore scans V versions to find the requested id. |
| search | O(N × H + M) | O(R) | For each non-trashed item, check visibility through ancestors and run strategy match cost M; keep R results. |
| subtree size | O(S) | O(D) | Folder size recursively visits S descendants with recursion depth D. |
The intentionally simple id lookup and permission walk keep the design interview-readable. Production systems add id indexes, cached effective ACLs, and search indexes, but the same Proxy boundary remains mandatory.
Extensibility
Richer ACL model
Replace the direct permission map with ACL entries containing inherited flags, link sharing, expiration, group ids, and domain policies. AccessProxy remains the only caller-facing decision point.
Search indexing
Add an observer that updates an inverted index when files are created, versioned, commented, trashed, or restored. DriveService.search can then delegate to the index after applying authorization filters.
Per-user starred state
Move starred from DriveItem to a UserItemMetadata record keyed by user id and item id. The service API does not change; only metadata storage changes.
Move and copy
Add moveItem requiring editor permission on source and destination parent. Guard against moving a folder into its own descendant and recompute inherited access through the Proxy.
Permanent delete and retention
Trash can become a state machine: active, trashed, retained, purged. The Proxy still controls who can transition states.
Alternative Designs
Permission checks inside every domain object
Each FileItem and FolderItem method could accept a user id and check ACLs before doing work.
Tradeoffs
This spreads authorization across many classes and makes inherited folder rules easy to implement inconsistently. It is weaker than a dedicated Proxy for this interview.
Flat item table instead of Composite
Store every item in a map by id with a parent id field and perform tree operations through queries rather than object ownership.
Tradeoffs
Closer to production persistence and faster id lookup, but it hides the Composite pattern and makes an LLD whiteboard less expressive. A repository can add this later behind the same objects.
Precomputed effective permissions
Materialize each user item effective permission when a folder is shared so reads are O(1).
Tradeoffs
Fast checks, but sharing a high-level folder becomes expensive and revocation is risky. The lazy Proxy walk is safer for the base design.
Common Mistakes
- ×
Focusing only on the file/folder Composite and forgetting that permissions are the harder requirement.
- ×
Checking permissions in UI/controller code and then letting services mutate items directly.
- ×
Treating folder shares and file shares as unrelated, so inherited access gives different answers in read, comment, and search.
- ×
Letting search return private item names before authorization filtering.
- ×
Making COMMENTER a boolean flag instead of part of an ordered permission ladder.
- ×
Overwriting old content during edit and losing version history.
- ×
Modeling trash as physical deletion, which prevents restore, audit, and retention policies.
Follow-up Interview Questions
QHow would you support link sharing?
Add a link token ACL entry with permission, expiration, and audience. AccessProxy first authenticates the token, then folds it into effective permission resolution without changing file or folder classes.
QHow do you make permission checks faster?
Keep the Proxy API but cache effective permission by user and item with invalidation on share, revoke, move, and trash. For large folders, use async materialization and versioned ACL epochs.
QWhat happens when a folder is shared as viewer but a child file is shared as editor?
The base Proxy checks the target item first, so the child direct EDITOR permission wins for that child. Siblings still inherit only viewer from the folder.
QHow would you prevent search from leaking private file names?
Always filter by AccessProxy.canView before applying a search strategy or returning any metadata. In production, the search index stores item ids and the serving layer joins with ACL filters.
QHow would move affect inherited permissions?
Move changes the ancestor chain, so effective access may change. Require editor access on both source and destination, perform the move atomically, and invalidate cached permissions for the moved subtree.
Production Considerations
Persistence and repositories
Store items, parent links, ACLs, versions, and user metadata in repositories. Keep domain methods clean and make DriveService the transaction boundary.
Authorization cache invalidation
Effective ACL caches must invalidate on share, revoke, ownership transfer, move, group membership change, and policy update. Incorrect stale allows are security incidents.
Search infrastructure
Use observers or an event log to update an inverted index asynchronously. Query results must still be ACL-filtered at serving time.
Version storage
Store content as blobs or deltas rather than full Java strings. Track checksums, creator, created time, and retention policy per version.
Audit and compliance
Emit immutable audit events for share, revoke, download, edit, restore, trash, and purge. Enterprise Drive products need traceability for compliance reviews.
What Interviewers Look For
Did the candidate explicitly make AccessProxy the central permission gate rather than an afterthought?
Can they explain direct permission, inherited folder permission, owner access, and override precedence clearly?
Is the Composite tree clean without forcing file behavior into folders or folder behavior into files?
Does search run after visibility filtering so it cannot leak private metadata?
Are versioning, starred state, trash, and observers modeled as extensions around the core authorization boundary?
Quiz
0/5 answered
1.Why is **AccessProxy** more important than the Composite tree in this Google Drive design?
2.What permission does **COMMENTER** include in this design?
3.A folder is shared with Bob as **VIEWER**, and a child file is shared with Bob as **EDITOR**. What should the Proxy return for that child file?
4.Why should search filter with **AccessProxy.canView** before returning matches?
5.What pattern does **SearchStrategy** apply?
Practice Variants
Add revoke and ownership transfer
AdvancedImplement revokePermission through DriveService and add transferOwnership. Define how inherited access and direct ACLs behave after ownership changes.
Add link sharing with expiry
ExpertCreate share links with permission, expiration time, and optional domain restriction. Keep token validation inside AccessProxy.
Index search with observers
AdvancedAttach an observer that updates an in-memory inverted index on file creation, versioning, comment, trash, and restore events. Preserve authorization filtering on query.
Support move and inherited ACL recalculation
ExpertAdd moveItem and decide how to invalidate cached permissions when an item moves between folders with different shares.
Flashcards
Cheat Sheet
Core objects: DriveService, AccessProxy, DriveItem, FileItem, FolderItem, Permission, VersionHistory.
Patterns: Composite for file/folder tree, Proxy for authorization, Strategy for search matching, Observer for activity and indexing events.
Permission rule: owner is effective editor; direct item ACL is checked before ancestor ACL; EDITOR includes commenter and viewer, COMMENTER includes viewer.
Main flows: create = require editor on parent then add child; read = require viewer then return content; comment = require commenter then append comment; edit = require editor then add version; share = require editor then add ACL.
Search rule: traverse visible tree, ignore trashed items, call AccessProxy.canView before applying SearchStrategy.
Versioning: every edit appends a version; restore appends an old snapshot as a new latest version.
Production upgrades: repositories, ACL caches, group permissions, link sharing, per-user starred metadata, search index, audit log, retention policy.
References
- BookDesign Patterns: Elements of Reusable Object-Oriented Software — Gamma, Helm, Johnson, Vlissides
- DocsRefactoring Guru — Proxy Pattern
- DocsRefactoring Guru — Composite Pattern
- DocsGoogle Drive API — Files and Permissions