Design and implement an in-memory cloud storage system that maps fully qualified file paths to file metadata (e.g., name and size). Do not use the real filesystem. Assume requests will not create collisions between file and directory names. Implement the following feature levels (passing earlier levels remains required at later levels): Level 1 — Basic file ops - bool AddFile(const std::string& name, int size): Add a new file path with size in bytes. Fail and return false if a file with the same path already exists. - bool CopyFile(const std::string& name_from, const std::string& name_to): Copy the file at name_from to name_to. Fail if name_from does not exist or is not a file, or if name_to already exists. Return true on success, false otherwise. - std::optional GetFileSize(const std::string& name): Return the file size if the file exists; otherwise return std::nullopt. Level 2 — File discovery - Support finding files by matching path prefixes and by matching suffixes (e.g., extension). Define clear APIs and choose data structures to make these queries efficient. Describe the expected time and space complexity. Level 3 — Users and capacity limits - Add a user concept with per-user storage capacity limits (in bytes). Associate files with users and enforce limits on AddFile/CopyFile. Specify error handling and what each API returns when limits would be exceeded. Level 4 — Compression support - Support compressing and decompressing files. Define APIs to compress/decompress a file and update stored size accordingly. Clarify whether GetFileSize returns logical (uncompressed) size or physical (stored) size, and how capacity accounting works under compression. General requirements - Keep everything in-memory. Provide class and method interfaces, core data structures (e.g., maps/tries/indexes), and justify trade-offs. Concurrency handling is optional but discuss how you would make operations thread-safe if needed. Include a brief test strategy and example scenarios demonstrating the expected behavior.

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design an in-memory cloud storage system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Take-home Project rounds at Ramp.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Ramp during technical interviews.

Design an in-memory cloud storage system

In-Memory Cloud Storage: Files, Discovery, Users, and Compression

Context: Design an in-memory storage library that maps fully qualified POSIX-style file paths (e.g., "/a/b/c.txt") to file metadata. There is no real filesystem; all data structures are in-memory. Assume requests will not create collisions between file and directory names (e.g., "/a" won't be both a file and a directory).

Requirements

Implement the following feature levels. Each later level must preserve and build on earlier behaviors.

Level 1 — Basic file operations

bool AddFile(const std::string& name, int size)
- Add a new file at path name with size in bytes.
- Return false if a file with the same path already exists; true otherwise.
bool CopyFile(const std::string& name_from, const std::string& name_to)
- Copy the file at name_from to name_to .
- Fail if name_from does not exist or is not a file, or if name_to already exists.
- Return true on success, false otherwise.
std::optional <int> GetFileSize(const std::string& name)
- Return the file size if the file exists; otherwise std::nullopt.

Level 2 — File discovery

Support finding files by:
1. Matching path prefixes (directory-like queries).
2. Matching suffixes (e.g., extension or arbitrary suffix).
Define APIs and choose data structures to make these queries efficient.
Describe expected time and space complexity.

Level 3 — Users and capacity limits

Add a user concept with per-user storage capacity limits (bytes).
Associate files with users and enforce limits on AddFile and CopyFile.
Specify error handling and what each API returns when limits would be exceeded.

Level 4 — Compression support

Support compressing and decompressing files.
Define APIs to compress/decompress a file and update its stored size accordingly.
Clarify whether GetFileSize returns logical (uncompressed) size or physical (stored) size, and how capacity accounting works with compression.

General constraints and deliverables

Keep everything in-memory. Do not use the OS filesystem.
Provide class and method interfaces and the core data structures (e.g., maps/tries/indexes). Justify trade-offs.
Concurrency handling is optional, but describe how you would make operations thread-safe.
Include a brief test strategy with example scenarios that demonstrate expected behavior.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?