Design an in-memory file system
PremiumLow-level designMedium
- Composite pattern
- Path resolution
- Tree structures
Quick answer
This low-level design interview question asks you to design an in-memory file system. Aim for a design that is modelled as clear classes, interfaces and relationships that can handle new requirements without a rewrite. Interviewers want to see how you name responsibilities, keep classes small and reason about change.
The problem
In-memory file system low level design: build the object model for a file system that lives entirely in memory, like the one a test harness or a sandboxed script runner uses. The hard parts are fast path lookup, moves that cannot create cycles, a size quota, and safe use by up to 32 threads.
It supports directories and files, absolute and relative paths, reading and writing file contents, moving and deleting entries, owners and permissions, and a total size quota.
What must an in-memory file system do?
- Tree: A root directory contains directories and files. Names are unique within a directory and limited to 255 characters.
- Paths: Resolve absolute paths such as /home/ana/notes.txt and relative paths with . and .. from a current working directory.
How well must it do it?
- Fast lookup: Resolving a path of depth d must cost O(d) and listing a directory with n children must not cost more than O(n log n).
- Concurrent: Up to 32 threads use the file system at once. Two writers to the same file must not interleave bytes; a reader must not see a half-written file.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Composite pattern
- Path resolution
- Tree structures
- Read write lock
- Permissions
- Storage quota
How you’ll practise
- Requirements
- Core objects
- Class relationships
- Key flows
- Extensibility
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any low-level design round.
- Lists the use cases before writing classes
- Gives each class one clear responsibility
- Uses interfaces where behaviour is likely to change
- Applies a design pattern only when it solves a real problem
- Handles edge cases and invalid states explicitly
- Walks through one use case end to end with the model
Questions people ask about this interview question
- Which design type is this question?
- It is a low-level design question. You design an in-memory file system and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Medium. Entry-level engineers can practise it, but it expects you to reason about requirements and trade-offs, not only list components.
- What should I cover first?
- Start with the use cases and the core entities, then the responsibilities of each one. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team