Welcome to Subscribe On Youtube

1500. Design a File Sharing System


We will use a file-sharing system to share a very large file which consists of m small chunks with IDs from 1 to m.

When users join the system, the system should assign a unique ID to them. The unique ID should be used once for each user, but when a user leaves the system, the ID can be reused again.

Users can request a certain chunk of the file, the system should return a list of IDs of all the users who own this chunk. If the user receives a non-empty list of IDs, they receive the requested chunk successfully.

Implement the FileSharing class:

  • FileSharing(int m) Initializes the object with a file of m chunks.
  • int join(int[] ownedChunks): A new user joined the system owning some chunks of the file, the system should assign an id to the user which is the smallest positive integer not taken by any other user. Return the assigned id.
  • void leave(int userID): The user with userID will leave the system, you cannot take file chunks from them anymore.
  • int[] request(int userID, int chunkID): The user userID requested the file chunk with chunkID. Return a list of the IDs of all users that own this chunk sorted in ascending order.



FileSharing fileSharing = new FileSharing(4); // We use the system to share a file of 4 chunks.

fileSharing.join([1, 2]);    // A user who has chunks [1,2] joined the system, assign id = 1 to them and return 1.

fileSharing.join([2, 3]);    // A user who has chunks [2,3] joined the system, assign id = 2 to them and return 2.

fileSharing.join([4]);       // A user who has chunk [4] joined the system, assign id = 3 to them and return 3.

fileSharing.request(1, 3);   // The user with id = 1 requested the third file chunk, as only the user with id = 2 has the file, return [2] . Notice that user 1 now has chunks [1,2,3].

fileSharing.request(2, 2);   // The user with id = 2 requested the second file chunk, users with ids [1,2] have this chunk, thus we return [1,2].

fileSharing.leave(1);        // The user with id = 1 left the system, all the file chunks with them are no longer available for other users.

fileSharing.request(2, 1);   // The user with id = 2 requested the first file chunk, no one in the system has this chunk, we return empty list [].

fileSharing.leave(2);        // The user with id = 2 left the system.

fileSharing.join([]);        // A user who doesn't have any chunks joined the system, assign id = 1 to them and return 1. Notice that ids 1 and 2 are free and we can reuse them.



  • 1 <= m <= 105
  • 0 <= ownedChunks.length <= min(100, m)
  • 1 <= ownedChunks[i] <= m
  • Values of ownedChunks are unique.
  • 1 <= chunkID <= m
  • userID is guaranteed to be a user in the system if you assign the IDs correctly.
  • At most 104 calls will be made to join, leave and request.
  • Each call to leave will have a matching call for join.



  • What happens if the system identifies the user by their IP address instead of their unique ID and users disconnect and connect from the system with the same IP?
  • If the users in the system join and leave the system frequently without requesting any chunks, will your solution still be efficient?
  • If all users join the system one time, request all files, and then leave, will your solution still be efficient?
  • If the system will be used to share n files where the ith file consists of m[i], what are the changes you have to make?


Use two maps to store each chunk and the users that own the chunk, and each user and the chunks owned by the user. Use a priority queue to store the IDs of the left users. Also maintain a max user ID.

For the constructor, initialize the two maps, the priority queue and set the max user ID to 0.

For method join, if the priority queue is empty, then increase the max user ID by 1 and assign the max user ID to the current user ID. Otherwise, poll the smallest element from the priority queue and assign it to the current user ID. Since the chunks are owned by the current user, update both maps. Finally, return the current user ID.

For method leave, if the user to chunks map contains the user ID as the key, update the chunk to users map to remove the user from the chunks, and remove the user ID from the user to chunks map. Finally, add the user ID to the priority queue.

For method request, first check whether the two maps contain the user ID and the chunk ID as a key respectively. If this is not the case, return an empty list. Otherwise, add the users that own the chunk into the result list, and update both maps. Finally, return the result list.

Follow up

1 . What Happens if the System Identifies the User by Their IP Address Instead of Their Unique ID and Users Disconnect and Connect from the System with the Same IP?

  • Dynamic IP Assignment: Users with dynamically changing IP addresses could be misidentified upon reconnection, leading to session continuity issues.
  • Multiple Users per IP: Shared IP scenarios (e.g., users on the same network) complicate unique user identification.


  • Session Tokens: Utilize session tokens for robust user identification, independent of IP changes.
  • IP and Unique Identifier: Combine IP address and a system-generated unique identifier upon joining for accurate user tracking.

2 . If the Users in the System Join and Leave the System Frequently Without Requesting Any Chunks, Will Your Solution Still Be Efficient?

  • Overhead with User Management: Frequent user status updates may lead to inefficiencies in managing user sessions and file metadata.


  • Optimized Data Structures: Employ hash tables or sets for efficient user and file metadata management.
  • Lazy Updates: Minimize metadata updates with strategies like lazy updates for users not interacting with files.

3 . If All Users Join the System One Time, Request All Files, and Then Leave, Will Your Solution Still Be Efficient?

  • Peak Load Management: A surge in file requests could strain the system, necessitating effective load distribution strategies.


  • Load Balancing and Rate Limiting: Implement these mechanisms to evenly distribute demand and prevent system overload.
  • Distributed File Storage and CDNs: Leverage these technologies for scalable file distribution and improved access times.

4 . If the System Will Be Used to Share n Files Where the i-th File Consists of m[i], What Are the Changes You Have to Make?

  • Variable Chunk Sizes: Managing files with differing numbers of chunks requires adaptable storage and retrieval mechanisms.


  • Chunk Metadata Management: Maintain detailed metadata for each file and its chunk composition in a scalable manner.
  • Dynamic Chunk Allocation: Adapt file distribution strategies based on chunk popularity, size, and user demand.
  • Customized File Request Handling: Adjust the file request process to efficiently handle files with varying chunk counts.

These adjustments aim to address the unique challenges presented by each scenario, ensuring the file-sharing system remains efficient and scalable.

More follow up

1. How would you scale the system to support millions of users and files?

  • Distributed Storage: Implement distributed file storage using technologies like Distributed Hash Tables (DHT) for efficient file lookup and distribution.
  • Load Balancing: Use load balancers to distribute requests evenly across servers, preventing any single server from becoming a bottleneck.
  • Caching: Implement caching strategies for frequently accessed files to reduce latency and decrease load on the storage system.

2. How can the system handle concurrent file uploads and downloads?

  • Locking Mechanisms: Use locks or synchronization primitives to manage concurrent accesses to the same file chunks, ensuring data consistency.
  • Version Control: Implement a version control system for files to handle concurrent edits and updates safely.

3. How would you improve the system’s fault tolerance and ensure data integrity?

  • Replication: Store multiple copies of file chunks across different servers or geographical locations to ensure availability in case of server failures.
  • Checksums and Hashing: Use checksums or hash values for files and chunks to detect and correct data corruption.

4. Can the system support real-time file collaboration or editing?

  • Operational Transformation (OT) or Conflict-Free Replicated Data Types (CRDTs): For real-time collaboration, implement algorithms like OT or use CRDTs to handle concurrent operations on documents without conflicts.
  • Event Sourcing: Store changes to files as a series of immutable events to enable collaborative editing and historical version tracking.

5. How would you implement user authentication and file access permissions?

  • Authentication Service: Integrate an authentication service (e.g., OAuth) to manage user identities and sessions securely.
  • Access Control Lists (ACLs): Use ACLs or role-based access control (RBAC) to define and enforce file access permissions based on user roles or identities.

6. How can the system be extended to support additional media types or large files?

  • Transcoding: Implement transcoding services to convert files into different formats or resolutions based on user needs or device capabilities.
  • Chunking and Streaming: For large files or media, use chunking to break files into smaller, manageable pieces and support streaming to allow users to start accessing content before the entire file is downloaded.

Addressing these follow-up questions would involve a combination of algorithmic solutions, architectural decisions, and leveraging existing technologies and protocols tailored to the specific requirements of a scalable, efficient, and reliable file-sharing system.

  • class FileSharing {
        private int chunks;
        private int cur;
        private TreeSet<Integer> reused;
        private TreeMap<Integer, Set<Integer>> userChunks;
        public FileSharing(int m) {
            cur = 0;
            chunks = m;
            reused = new TreeSet<>();
            userChunks = new TreeMap<>();
        public int join(List<Integer> ownedChunks) {
            int userID;
            if (reused.isEmpty()) {
                userID = cur;
            } else {
                userID = reused.pollFirst();
            userChunks.put(userID, new HashSet<>(ownedChunks));
            return userID;
        public void leave(int userID) {
        public List<Integer> request(int userID, int chunkID) {
            if (chunkID < 1 || chunkID > chunks) {
                return Collections.emptyList();
            List<Integer> res = new ArrayList<>();
            for (Map.Entry<Integer, Set<Integer>> entry : userChunks.entrySet()) {
                if (entry.getValue().contains(chunkID)) {
            if (!res.isEmpty()) {
                userChunks.computeIfAbsent(userID, k -> new HashSet<>()).add(chunkID);
            return res;
     * Your FileSharing object will be instantiated and called as such:
     * FileSharing obj = new FileSharing(m);
     * int param_1 = obj.join(ownedChunks);
     * obj.leave(userID);
     * List<Integer> param_3 = obj.request(userID,chunkID);
  • class FileSharing:
        def __init__(self, m: int):
            self.cur = 0
            self.chunks = m
            self.reused = []
            self.user_chunks = defaultdict(set)
        def join(self, ownedChunks: List[int]) -> int:
            if self.reused:
                userID = heappop(self.reused)
                self.cur += 1
                userID = self.cur
            self.user_chunks[userID] = set(ownedChunks)
            return userID
        def leave(self, userID: int) -> None:
            heappush(self.reused, userID)
        def request(self, userID: int, chunkID: int) -> List[int]:
            if chunkID < 1 or chunkID > self.chunks:
                return []
            res = []
            for k, v in self.user_chunks.items():
                if chunkID in v:
            if res: # update ownership map
            return sorted(res)
    # Your FileSharing object will be instantiated and called as such:
    # obj = FileSharing(m)
    # param_1 = obj.join(ownedChunks)
    # obj.leave(userID)
    # param_3 = obj.request(userID,chunkID)

All Problems

All Solutions