Design a File Sharing System - Problem
Design a File Sharing System that efficiently manages user access to file chunks in a peer-to-peer network.
You're building a system similar to BitTorrent where a large file is divided into
Your system must handle:
•
•
•
The challenge is to efficiently track user IDs, manage chunk ownership, and quickly find users who own specific chunks.
You're building a system similar to BitTorrent where a large file is divided into
m small chunks (numbered 1 to m). Users can join the system, own certain chunks, and request chunks from other users.Your system must handle:
•
join(ownedChunks[]) - Assign the smallest available user ID to a new user•
leave(userID) - Remove a user and make their ID available for reuse•
request(userID, chunkID) - Return all users who have the requested chunkThe challenge is to efficiently track user IDs, manage chunk ownership, and quickly find users who own specific chunks.
Input & Output
example_1.py — Basic Operations
$
Input:
FileSharing(4)\nfs.join([1,2]) # User joins with chunks 1,2\nfs.join([2,3]) # Another user joins\nfs.request(1, 2) # Request chunk 2
›
Output:
1\n2\n[1, 2]
💡 Note:
First user gets ID 1, second user gets ID 2. When requesting chunk 2, both users 1 and 2 have it, so return [1, 2] in sorted order.
example_2.py — Leave and ID Reuse
$
Input:
FileSharing(3)\nfs.join([1]) # User 1\nfs.join([2]) # User 2\nfs.leave(1) # User 1 leaves\nfs.join([1,3]) # New user
›
Output:
1\n2\n\n1
💡 Note:
After user 1 leaves, their ID becomes available. The next user to join gets the smallest available ID, which is 1 (reused).
example_3.py — Empty Request
$
Input:
FileSharing(5)\nfs.join([1,2])\nfs.request(1, 5) # Request chunk no one has
›
Output:
1\n[]
💡 Note:
When requesting a chunk that no active user owns, return an empty list [].
Visualization
Tap to expand
Understanding the Visualization
1
Member Registration
New members get the lowest available membership number and register which chapters they own
2
Chapter Index
The library maintains an instant-lookup index showing which members have each chapter
3
ID Recycling
When members leave, their ID cards go into a priority recycling bin for reuse
4
Chapter Requests
Anyone can instantly find all members who have a specific chapter
Key Takeaway
🎯 Key Insight: The combination of hash tables for instant chunk lookups and a min-heap for ID management creates an optimal system that scales efficiently with both user count and chunk requests.
Time & Space Complexity
Time Complexity
O(1)
Hash table lookups and heap operations are O(log n) for ID management, but O(1) for chunk queries
✓ Linear Growth
Space Complexity
O(n*m)
Hash tables store user-chunk mappings and chunk-user mappings
⚡ Linearithmic Space
Constraints
- 1 ≤ m ≤ 105
- 0 ≤ ownedChunks.length ≤ min(100, m)
- 1 ≤ ownedChunks[i] ≤ m
- Values in ownedChunks are unique
- 1 ≤ chunkID ≤ m
- userID is guaranteed to be a user in the system if you assign it
- At most 104 calls will be made to join, leave and request
- Each user will own at most 100 chunks
💡
Explanation
AI Ready
💡 Suggestion
Tab
to accept
Esc
to dismiss
// Output will appear here after running code