Imagine a client-server app that lets user upload images/documents etc. to server and then lets users who have access, retrieve and view them later on their respective mobile devices.

So the flow is something like this:

  • Creator (C) creates a message with n number of attachments.
  • C uploads the files and message to server via REST API.
  • Recipients R1, R2... Rn get notified about new content
  • R1, R2, and other go in on their own times and fetch the message and attachments.
  • Once downloaded, the mobile app doesn't request server the next time any of the recipients tries to view the attachments, it uses locally cached data.

Now the creator C already has the files (since it created them) and need not download them again. So when it gets a response from server like:

  messageId: 123,
  attachments : [ { id: a1, ...}, {id: a2, ...}, {id: a3, ...} ]

However, it doesn't know which attachment is what (i.e. which one is a1 and which one is a2 and so on).

It just knows that message #123 has 3 attachments.

What would be a good way to figure this out? There are 2 approaches that come to my mind:

Approach #1: use file hash

  • Calculate file hash (MD5 or SHA) and use that as a key on the mobile app.
  • Server does the same and returns the hash as identifier instead of a generated id.


  • No extra metadata is needed for sync


  • Probably error prone - hash may not match due to OS or hash implementation differences
  • Hashing will be slow for big files

Approach #2: use a key

  • App generates an UUID and sends it to server as an identifier.
  • Server stores it and returns the key with the response for syncing.


  • Hash related errors are eliminated
  • Hashing speed is not a concern since UUID generation is pretty quick and deterministic.


  • And extra key is passed between app/server which has no other purpose.

Which one of these is preferable? Or maybe there is a 3rd option?

  • "Neither" might be a surprisingly valid option. The only reason I can think of for the "creator" downloading their own attachments would be to check if the attachment/download process is working successfully, in which case giving him any special caching treatment would actually be undesirable. Would users of your app have another reason? – Ixrec Jan 14 '16 at 23:35
  • I can think of few: a) Someone else decides to collaborate and adds one or more attachment. Creator sees that there are more attachments now but doesn't know which ones to request from server (w/o key synchronization it doesn't know which is which). b) Creator deletes one or more attachments from the message. Now instead of just passing the key/id to the server and asking it to delete, it has to send the remaining attachments again and server has to drop and re-insert again (not only an unnecessary blob op but if CDNs are involved, the deletion has to ripple out). There are more such scenarios – Mrchief Jan 14 '16 at 23:51
  • but suffice to say that for whatever reason, key synchro is needed (unless these issue can be mitigated thru some other means). Now if the message was non-editable, i.e. once created cannot be modified, then probably no snychro can be a viable option. – Mrchief Jan 14 '16 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.