Requirements for the File Storage System

Let's define what our file storage system must do. Each requirement is specific enough to drive at least one class or method in our design.

1. R1 — File Upload: Users shall upload files of any type (documents, images, videos, archives). The system shall store the file content and associated metadata (name, size, MIME type, created/modified timestamps).

2. R2 — File Download: Users shall download any file they have access to. The system returns the file content along with its metadata.

3. R3 — Folder Hierarchy: Users shall create folders and nest them to any depth, forming a tree structure. Every file lives inside exactly one folder. Every user has a root folder created automatically on signup.

4. R4 — Move & Rename: Users shall rename files and folders, and move them to a different parent folder within their own storage.

5. R5 — Delete & Trash: Deleting a file or folder moves it to a Trash area rather than permanently removing it. Users can restore items from Trash or permanently delete them. Deleting a folder recursively trashes all its contents.

6. R6 — Sharing & Permissions: Users shall share files or folders with other users or groups. Each share specifies an access level: Viewer (read-only), Editor (read + write), or Owner (full control including re-sharing and deletion). Permissions on a folder cascade to all descendants unless overridden.

7. R7 — User & Group Management: The system supports individual user accounts and named groups. A group contains one or more users. Sharing with a group grants the specified access level to every member.

8. R8 — File Versioning: Each upload of an existing filename in the same folder creates a new version rather than overwriting. Users can list all versions of a file and restore any previous version.

9. R9 — Chunked Upload: Large files (above a configurable threshold, e.g., 5 MB) shall be uploaded in fixed-size chunks. The system reassembles chunks into the complete file. If an upload is interrupted, only the missing chunks need to be re-sent.

10. R10 — Deduplication: The system shall detect duplicate content using content hashing (SHA-256). If two files have identical content, only one physical copy is stored. This applies across all users.

11. R11 — Search: Users shall search for files and folders by name within their accessible storage. The search returns matching items the user has permission to view.

12. R12 — Storage Quota: Each user has a configurable storage quota. Uploads that would exceed the quota are rejected. Quota tracks logical file sizes (before deduplication) to maintain billing fairness.

Beyond functionality, the design must satisfy these quality attributes:

1. Extensibility (Open/Closed Principle): Adding a new storage backend (local disk, S3, Azure Blob) must not require changes to existing classes. The storage layer uses a strategy interface.

2. Testability: Every component — permission checks, chunking logic, deduplication, folder traversal — must be testable in isolation through dependency injection and clear interfaces.

3. Thread Safety: Multiple users may upload to the same folder, modify the same file's permissions, or delete items concurrently. Critical operations (quota check + upload, permission grant) must be atomic or properly synchronized.

4. Performance: File tree traversal for permission cascading should be efficient. Searching by name should not require a full tree walk — we'll maintain a lightweight index.

5. Data Integrity: Interrupted chunked uploads must not leave partial files visible. Only fully assembled files appear in the user's folder. Hashes must be verified after reassembly.

In Scope:

• File and folder CRUD (create, read, update, delete)
• Hierarchical tree structure with the Composite Pattern
• Permission model with cascading and group-based sharing
• Chunked upload and reassembly logic
• Content-based deduplication via SHA-256 hashing
• File versioning (version list, restore)
• Name-based search across accessible files
• Storage quota enforcement
• Storage backend abstraction (Strategy Pattern)

Out of Scope:

• Real-time sync / conflict resolution — that's a distributed systems concern (System Design level)
• Database schema / ORM — we model domain objects, not database tables
• REST API design — endpoints and HTTP verbs are a system design topic
• Encryption at rest / in transit — security infrastructure, not domain modeling
• Thumbnail generation / preview rendering — media processing pipeline
• Activity log / audit trail — useful but not core to the object model

Every requirement should map to at least one class in our upcoming class diagram. Here's a preview of how they connect:

Requirement	Primary Class(es)	Key Pattern
R1 — File Upload	File, StorageService, StorageBackend	Strategy
R2 — File Download	StorageService, StorageBackend	Strategy
R3 — Folder Hierarchy	FileSystemNode, File, Folder	Composite
R4 — Move & Rename	Folder, FileSystemNode	Composite
R5 — Delete & Trash	TrashService, FileSystemNode	—
R6 — Sharing & Permissions	Permission, AccessLevel, ShareService	—
R7 — User & Group Mgmt	User, Group	—
R8 — File Versioning	FileVersion, VersionService	—
R9 — Chunked Upload	Chunk, ChunkedUploadSession	—
R10 — Deduplication	ContentStore, Chunk	—
R11 — Search	SearchService	—
R12 — Storage Quota	User (quota fields), StorageService	—

This traceability ensures no requirement is "orphaned" — every one produces at least one class, attribute, or method in the design.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Ask questions like:

• "Should the system support sharing with external users (outside the organization), or only internal users?"
• "Do we need real-time collaboration (like Google Docs), or is upload/download sufficient?"
• "Is deduplication across users acceptable, or does each user get isolated storage?"
• "What's the maximum file size we should support? Does the system need resumable uploads?"
• "Should deleted files be recoverable? If so, for how long?"

These questions demonstrate design maturity and help you scope the problem appropriately. An interviewer who says "let's skip real-time collab" just removed a huge complexity vector from your design — that's a win.