Problem: Design a Production-Grade File Storage Service
Design a production-grade file storage service that offers the following APIs, adheres to specified semantics and constraints, and scales to meet demanding requirements.
APIs
addFile(String path)- Creates any missing folders in the specified path and stores a file at a given path (e.g., "path/to/somewhere/file.txt").
list(String path)- Returns the immediate children (both files and folders) of the directory located at the provided path.
Constraints and Semantics
- Per-Directory Capacity Limit: Each directory can contain a maximum of 5 entries, which includes both files and subfolders. Any attempt to exceed this limit must be atomically rejected.
- Name Collision Handling: If a file is added to a directory where another file with the exact same name already exists, the new file must be automatically renamed using an OS-style suffix. For example,
base.extwould becomebase (1).ext, thenbase (2).ext, and so on. The system must correctly handle input paths that already contain such suffixes (e.g.,base (1).ext) by not double-suffixing, accepting the name if it's free, or continuing the numbering sequence if it's taken.
Required Discussion Points
Your design should cover the following aspects:
- Overall Architecture: Detail the API layer, metadata service, and content store components.
- Metadata Management: Describe the metadata schema and justify your choice of metadata store (e.g., relational vs. NoSQL).
- Atomic Operations: Explain how the per-directory capacity limit and file renaming are enforced atomically under concurrent requests.
- Transaction Management: Discuss transaction boundaries and idempotency considerations.
- Content Storage: Address whether content is location-addressed or content-addressed, and how file bytes are physically stored (e.g., references to object storage).
- Large File Handling: Detail strategies for streaming and resumable uploads for large files.
- Consistency & Reliability: Define the consistency model and outline mechanisms for failure handling and rollback.
- Scalability: Describe partitioning keys, sharding strategies, and caching mechanisms to ensure scalability.
- Operational Aspects: Cover observability, rate limiting, and quota enforcement.
- Data Lifecycle: Explain how data retention, deletion, and versioning are managed.
- Security: Address authentication, authorization, path traversal protection, and encryption (in transit and at rest).
- Service Level Objectives: Define key SLIs (Service Level Indicators) and SLOs (Service Level Objectives).
Assumptions
- The service operates within a single logical namespace with a root directory.
- It supports multi-tenant users.
- You may introduce minimal additional endpoints (e.g., for upload sessions) to realistically implement large-file handling.
AI interview prep
Core dilemma
Achieving strong consistency and atomicity for metadata operations (like directory capacity limits and file renaming) in a highly concurrent, distributed file storage system, while maintaining scalability, availability, and performance.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Problem: Design a Production-Grade File Storage Service
Design a production-grade file storage service that offers the following APIs, adheres to specified semantics and constraints, and scales to meet demanding requirements.
APIs
addFile(String path)- Creates any missing folders in the specified path and stores a file at a given path (e.g., "path/to/somewhere/file.txt").
list(String path)- Returns the immediate children (both files and folders) of the directory located at the provided path.
Constraints and Semantics
- Per-Directory Capacity Limit: Each directory can contain a maximum of 5 entries, which includes both files and subfolders. Any attempt to exceed this limit must be atomically rejected.
- Name Collision Handling: If a file is added to a directory where another file with the exact same name already exists, the new file must be automatically renamed using an OS-style suffix. For example,
base.extwould becomebase (1).ext, thenbase (2).ext, and so on. The system must correctly handle input paths that already contain such suffixes (e.g.,base (1).ext) by not double-suffixing, accepting the name if it's free, or continuing the numbering sequence if it's taken.
Required Discussion Points
Your design should cover the following aspects:
- Overall Architecture: Detail the API layer, metadata service, and content store components.
- Metadata Management: Describe the metadata schema and justify your choice of metadata store (e.g., relational vs. NoSQL).
- Atomic Operations: Explain how the per-directory capacity limit and file renaming are enforced atomically under concurrent requests.
- Transaction Management: Discuss transaction boundaries and idempotency considerations.
- Content Storage: Address whether content is location-addressed or content-addressed, and how file bytes are physically stored (e.g., references to object storage).
- Large File Handling: Detail strategies for streaming and resumable uploads for large files.
- Consistency & Reliability: Define the consistency model and outline mechanisms for failure handling and rollback.
- Scalability: Describe partitioning keys, sharding strategies, and caching mechanisms to ensure scalability.
- Operational Aspects: Cover observability, rate limiting, and quota enforcement.
- Data Lifecycle: Explain how data retention, deletion, and versioning are managed.
- Security: Address authentication, authorization, path traversal protection, and encryption (in transit and at rest).
- Service Level Objectives: Define key SLIs (Service Level Indicators) and SLOs (Service Level Objectives).
Assumptions
- The service operates within a single logical namespace with a root directory.
- It supports multi-tenant users.
- You may introduce minimal additional endpoints (e.g., for upload sessions) to realistically implement large-file handling.