1

Consider a facebook-like application and following sequence of actions:

  1. Application submits post-content to the server
  2. Server associates a UUID to that post-content and inserts the post in a KV-store against that key. Server also successfully
  3. Server is unable to send response OR App is unable to get a response back because of network failure between the Server and the App
  4. App retries the upload of the post. Server repeats steps 1-2. This time succeeds to enter an entry into the KV-store

At this point, the KV-store has duplicate entries for the post and the user will see 2 entries for the post.

How do Facebook-like apps address this problem.

I believe the only solution to this problem is to have idempotency of requests and that will only be possible if the App re-uses the same ID when re-submitting the same request.

user855
  • 19,048
  • 38
  • 98
  • 162

1 Answers1

0

I think it completely depends on the business considerations. Sometimes we upload multiple posts with the same content on Instagram so we should keep one of them by deleting others. If there is a case that users are not allowed to create multiple data with the same content then they should get an error of duplication (409 status code). this is my all-time solution. maybe I did not get your point of view about that problem. so after reading your comments and a long while of searching around your issue finally I would recommend using an uuid like mechanism to prevent duplicate data due to any network failure before receiving success status from the app side. here is a procedure for this solution.

1. Create a unique UUID in your app.
2. Send the ID from step 1 with your post.
3. Store this ID inside the post that the user tried to send it also store it in your database.
4. If the user did not get any response from step 2 after a while.
   4-a. On the next try send the UUID to check the status
   4-b. If the status is not success go to step 2.
5. show the user that the post was submitted without any error.
Heartbit
  • 1,698
  • 2
  • 14
  • 26
  • If the "USER" wants to re-upload same post 2 times, we should allow it. But my example was about the Mobile app retrying the upload upon 1st failure. In that case, the USER only uploaded post 1 time, but it will show up 2 times in the timeline because the Mobile app inserted it 2 times accidentally. The Server has no way to know that the 2nd post is a retry of the 1st and de-dupe it. It will just create a new ID for 2nd attempt and insert a new row instead of returning 409 error code. Does this help explain my example? – user855 Dec 16 '21 at 17:56
  • @user855 please share your thoughts about this solution – Heartbit Dec 27 '21 at 13:24
  • Client-generated IDs (or Dedupe-IDs if server is generating the primary key) are REQUIRED if there is a use-case to de-dupe content for supporting idempotent operations. The default De-dupe ID might as well be the SHA512 hash but some kind of deduce ID is still needed. – user855 Dec 30 '21 at 01:06