Home/ Questions/Q 9088487
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T21:55:01+00:00

I need to store friend relationships for users in MongoDB, using Spring Data. My

  • 0

I need to store friend relationships for users in MongoDB, using Spring Data. My “schema” solution is to store the username (which is also the _id) of friends inside the user document. I’m not using DBRef because there seems to be a problem with Spring Data and DBRef on a self relationship (friends are users :p). A simple user document is something like this:

{
"_id" : "user1",
"email" : "user1@test.com",
"friendRequests" : {
    "user4" : 0
},
"friends" : ["user2", "user3" ],
"password" : "$2a$10$9iJWLZjBSu3rq19wh7KTduNXIVcXozsNVjwVogO9eoz0uXO52Z2NC"
}

I think this model in good enough. But when someone accept a friend request, I have to update both users’ documents and the operation is not atomic. There could be some case where only one of the two gets updated. It’s not critical data, but still would be nice to have a solution for this. Am I overthinking this? I found this document on 2 phase commit http://cookbook.mongodb.org/patterns/perform-two-phase-commits/ but it seems too much for this situation, even though it’s pretty easy to implement.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It’s hard to answer these type of questions without knowing how your application will be using the data. Remember, in MongoDB there are many different ways to represent basically the same data/schema, so the way that will work best with your application is the one that fits your application’s needs.

    Some questions to ask yourself:
    Do you know how many friends on average each user will have?
    How will you be displaying/querying/updating user’s friends?
    Which of the above operations need to be performant and absolutely up-to-date and which can take longer, or be done in batch mode later?

    There are trade-offs to each possible schema for your data. Continually adding usernames into an array of friends of each user means the documents will continually grow (this is sub-optimal for performant update as when the document exceeds its allocated space it needs to be moved the next time it’s updated). To offset that, you have to consider what you gain when you store an array of friends this way. Does it enable you to make only a single read when fetching all information about the user? Or do you still need to make another read (maybe querying the users collection again for additional information about each user which is in the friends array?

    You are already thinking about atomicity of updates which help keep the data consistent, but as you correctly note, this is something that your application can handle (or you can have a background job which runs and detects any “part-way” friendship updates and cleans them up).

    You should also consider how you will need to index the collections – if you need many indexes on a single collection to satisfy the SLA for your queries, then your updates/inserts will necessarily get slower (since many more indexes will need to be updated). That may be okay but only you can make the decision about the trade-off.

    I hope this helps.

    • 0