I read at https://docs.mongodb.com/realm/sync#use-case-profiles-and-scalability that a realm can handle 30 concurrent writers, but performance drops beyond that because of conflict resolution overhead.
I can see why there would be conflicts if users write to the same object, but assuming they all write to a separate object in the same realm, would the overhead still occur?
At the realm level, it is a “Multiple writer, multiple reader” case, however at the object level, it is more of a “Single writer, multiple reader” case. Which one is more relevant?
1 Like
I have close to the same question and while I don’t see a response, I’m wondering if anyone knows the answer?
My situation is that I’m creating a scavenger hunt app.
When someone creates a hunt, that will be it’s own realm.
The hunt has a list of tasks for each person to do.
Then each task has a list of posts that each person creates when they do the task.
Does the 30 concurrent writers mean that only 30 people can access the hunt realm at a time? Or just that submitting the post can only be 30 per second? Could, say 1000 people be doing the hunt and as long as they aren’t all writing a new post at the same time, it won’t be an issue? Or is it that it would never be an issue because each person is writing a post, but since no one is writing or updating the same post that it would only always be 1 concurrent writer?
Any explanation would be appreciated before getting too far into this and realizing that Realm can’t handle it.
Thanks.
–Kurt
1 Like
Guys, all of these are great questions. My understanding is that the scalability can only really be managed by properly architecting the realm partitions. For example, if you were writing a chat program, you would not want to put all of the chats between all of the users in the same realm. You would basically want to segment each chat thread into a separate realm. Ok, but then how would you implement a telegram chat thread with a 100K users? Again, you would have to become clever with the architecture. In that case, each user would write chat entries to their private realm (partition key = user id), and a back end trigger would add it to the chat thread realm, which would only be read-only by the various users of the thread. By the way, you can substitute “chat” thread for “scavenger hunt teams”, and the arguments are identical.
I had this exact conversation with Robert Oberhofer from MongoDB about a year ago at the Live event. He is the head of Product Solutions at Realm. According to Robert, you can have as many Realms (now partitions) as possible. That is the key to scalability. What you simply want to avoid is more than 30 users writing simultaneously to the same Realm or partition.
I hope this was useful.
Richard Krueger
1 Like
Perfect. That’s very helpful.
Realm functions really save the day on this. Being able to design the functions well is another level of separating the business logic that I haven’t done in mobile app development, but it also prepares apps to spread to other platforms much more readily since the business logic doesn’t need to be repeated.
1 Like
I will second what @Kurt_Libby1 wrote by adding this. Server side functions and triggers are perhaps the single best feature of the new MongoDB Realm product since June 2020. This was something that was really missing in the old Realm Sync product - where you would have to spin up a server and implement the backend processing as a Node.js program. And whenever you force a developer to spin up a server, it takes away from the whole server-less programming story.
To the engineering and product management teams at MongoDB, it would be great for a future release of the product if you could architect a mechanism (similar to Cocoa Pods) for installing third party functions and triggers onto a MongoDB Realm Application. This can be done in a rather convoluted way using the Realm Admin API, but requires the developer to assemble a number of keys for that to take place. And it would even be better if you could architect a payment system (similar to the Apple App Store) to go alongside of it. A man can dream…
Richard Krueger
In case it is helpful to anyone else in modeling, this is what I’m thinking.
Would appreciate any feedback if you see any problems with scaling, but this should make it so that everyone is always writing to their own realm and the only reason there would be more than 30 is if someone logged into their own account on 30+ devices, which is pretty far outside of the scope of this application.
So the Hunt Realm should only be readable by the users who are part of the “hunt”, not all users in the system. Basically, any updates would happen in the user realm and those updates would be marshaled on to the hunt realm by a backend trigger function.
I guess you would only need to follow this strategy if a particular hunt had more than 30 people concurrently. You may have thousands of users but never really more than 30 in any particular hunt at a time. If there were the case you probably wound not need the user realm/hunt realm marshaling. But if that is not the case, you probably will.
Richard
Yeah, the thought is to gate the amount of users in a hunt where they could do an IAP to increase the number and that could become much more than 30 as in the 1000s. That’s where the issue comes in.
Technically speaking, I think the hunt realm could be readable by everyone because it will only show if your user object has created or joined the hunt by adding the hunt partition id to user.huntsCreated or user.huntsJoined in the user profile object.
The way I’m designing and thinking about it right now, there would be a code (hunt.code) that is input to join a hunt. In the future, I may want to create a listing of available hunts that you have not joined. If that’s the case, it would need to be readable by anyone even if you haven’t joined yet.
I don’t think there is a security concern because it is read only and not necessarily sensitive at all, but if you see any holes, I’d love to adjust this sooner rather than later.
Kurt,
The most secure scenario is where you give your user read/write access only to their private user realm. Let the server handle all the other writes to the hunt realms.
You will probably have to use Custom User Data to handling the sync permissions for each hunt realm.
Richard
1 Like
