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 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 chunk

The 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
File Sharing System ArchitectureActive Users1[1,3,5]2[2,4]4[1,2,6]User 3 left → ID availableChunk → Users IndexChunk 1: [User 1, User 4] ⚡Chunk 2: [User 2, User 4]Chunk 3: [User 1]Chunk 4: [User 2]O(1) Direct Lookup!Available IDs(Min Heap)379Next new user gets ID 3Efficient O(log n) reuseSystem OperationsJOINGet smallest IDUpdate mappingsREQUESTO(1) hash lookupReturn sorted listLEAVERemove mappingsRecycle IDPERFORMANCESpace: O(U×C)Request: O(1)Fast Chunk Lookup🎯 Key Insight: Hash tables + Min heap = O(1) requests + Efficient ID reuse
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

n
2n
Linear Growth
Space Complexity
O(n*m)

Hash tables store user-chunk mappings and chunk-user mappings

n
2n
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
Asked in
Amazon 45 Google 38 Microsoft 32 Meta 28
21.5K Views
Medium-High Frequency
~25 min Avg. Time
890 Likes
Ln 1, Col 1
Smart Actions
💡 Explanation
AI Ready
💡 Suggestion Tab to accept Esc to dismiss
// Output will appear here after running code
Code Editor Closed
Click the red button to reopen