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 medium difficulty System Design question, commonly asked during Take-home Project rounds at Coinbase.

What role is this question designed for?

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

Design cloud storage system | Coinbase Interview Question

Quick Overview

This question evaluates competence in system design, in-memory data structures, multi-tenant state management, API design, and operational semantics (capacity enforcement, merge/rename rules, and versioned backups) and is classified in the System Design domain; it probes both conceptual understanding and practical application.

In-Memory Cloud Storage: Design and Implement

You are asked to design and implement an in-memory cloud storage system that maintains a mapping from file names to their metadata (size) and supports both single-user and multi-user operations.

Assumptions to make explicit:

File names are unique per user. The early single-user functions operate in a special default user namespace.
Sizes are non-negative integers (bytes). Capacity is the maximum total size (sum of file sizes) allowed per user.
For get_n_largest(prefix, n), return the n largest files across all users whose names start with prefix. Each result should identify the user.
merge_user(u1, u2) combines user2 into user1; user1 remains, user2 is deleted. Capacity becomes the sum of both users' capacities.
If file name collisions occur during merge, rename the incoming conflicting file(s) from user2 by appending a suffix to ensure uniqueness (e.g., "name (merged 2)").
backup_user and restore_user operate per user and do not affect other users' files or capacities.

Required API

Single-user (default namespace):

add_file(name, size)
get_file_size(name) → size or None
delete_file(name)
get_n_largest(prefix, n) → list of (user_id, name, size)

Multi-user:

add_user(user_id, capacity)
add_file_by(user_id, name, size) // enforce per-user capacity limits
merge_user(user_id1, user_id2) // combine users and their files; capacity sums; rename on conflicts
backup_user(user_id) → version_id // versioned backups per user
restore_user(user_id, version_id=None) // restore to a saved version (latest if None)

Deliverables

Data structures and algorithms to support the operations.
Clear semantics for edge cases (e.g., capacity enforcement, file collisions on merge, restore behavior).
Time/space complexity discussion and potential optimizations for prefix queries.
A working in-memory implementation (any mainstream language) with small usage examples/tests.

Quick Overview

In-Memory Cloud Storage: Design and Implement

You are asked to design and implement an in-memory cloud storage system that maintains a mapping from file names to their metadata (size) and supports both single-user and multi-user operations.

Assumptions to make explicit:

File names are unique per user. The early single-user functions operate in a special default user namespace.

Sizes are non-negative integers (bytes). Capacity is the maximum total size (sum of file sizes) allowed per user.

For get_n_largest(prefix, n), return the n largest files across all users whose names start with prefix. Each result should identify the user.

merge_user(u1, u2) combines user2 into user1; user1 remains, user2 is deleted. Capacity becomes the sum of both users' capacities.

If file name collisions occur during merge, rename the incoming conflicting file(s) from user2 by appending a suffix to ensure uniqueness (e.g., "name (merged 2)").

backup_user and restore_user operate per user and do not affect other users' files or capacities.

Required API

Single-user (default namespace):

add_file(name, size)

get_file_size(name) → size or None

delete_file(name)

get_n_largest(prefix, n) → list of (user_id, name, size)

Multi-user:

add_user(user_id, capacity)

add_file_by(user_id, name, size) // enforce per-user capacity limits

merge_user(user_id1, user_id2) // combine users and their files; capacity sums; rename on conflicts

backup_user(user_id) → version_id // versioned backups per user

restore_user(user_id, version_id=None) // restore to a saved version (latest if None)

Deliverables

Data structures and algorithms to support the operations.

Clear semantics for edge cases (e.g., capacity enforcement, file collisions on merge, restore behavior).

Time/space complexity discussion and potential optimizations for prefix queries.

A working in-memory implementation (any mainstream language) with small usage examples/tests.

Design cloud storage system

Quick Overview

In-Memory Cloud Storage: Design and Implement

Required API

Deliverables

Solution

Comments (0)

Design cloud storage system

Quick Overview

In-Memory Cloud Storage: Design and Implement

Required API

Deliverables

Solution

Comments (0)