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 [].

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

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