Designing Dropbox

I think there is a chance of collision while computing the hash of chunks because there are too many chunks stored. What if different chunks have the same hash? The file will be corrupted when reconstructing them, won't they?

Why do I need long pooling if i have response queues and notification service to deliver updates to other clients?

Just thinking loud, If the User is a celebrity or high profile user or taken some premium service and the user got too much space in any file system and then he/she created 1 directory and put like lot of image or video files lets say data in TB then what would happen? The complete directory will be in one partition.

In the detailed diagram it shows that the metadata is updated first and then it is sent to the synchronizing service but in the text explanation, it’s vice versa… which flow should we consider?

The final diagram has LBs for Metadata Servers but not Block Serveres. I believe its required and the diagram should be corrected.

Data Duplication for Fault Tolerance is not discussed in this system design ?

With same idea, can someone explain how to scale 1 server to upload a 20 gb file to 20 server and then scaling up to 10000 server in same data center.

Can Memcached be used to store chunks of data? Since, it is a key-value store.

Question about the message queue. Based on the text, it seems one user can have multiple clients (mobile, pc, web, etc.). And the backend needs to maintain a response queue for each of the clients. Now we have 500M users and 3 devices per user. So we are maintaining 1.5B response message queues. Isn't that quite a big scaling challenge? Also, we can we add a chapter for MQ in the system design basics section?

how would synchronization work if separate clients make changes to the same file that affect different chunks, but the updated chunks in combination would result in a corrupted file?

Is that possible?