Backend Design for Messaging Module on Native Mobile – Best Practice?

0
Hi, I’m developing a messaging module for a Native Mobile application. My goal is to maintain a modular structure so that this module can be integrated into different applications without any modifications. On the other hand, since I’m developing for Native Mobile, I want to avoid using unnecessary entities as much as possible. As a result, I’m currently stuck on the backend design.   Specifically, I’m trying to decide how to model the Message entity. I’m considering three possible approaches: 1) Message → Balance (1–*) Relations: Balance has a 1–1 association with Profile, and Profile has a 1–1 association with Account. (Attachment 1) Pros: Supports a modular structure; all relationships are tied to the Balance entity. Cons: Messages would be linked to the Balance entity for all profiles. All points given and available points would reside in Balance. Requires multiple-level INNER JOINs in OQL. For example, to find the user who gave the most points, I need filtered queries reaching the Account level. (Considering around 15k users, I want the application to remain performant.) I have to sync Balance entity whenever new user logins to application. (We are planning to place the logic on when Provisioning user) 2) Message → Profile (1–*) Relations: Profile has a 1–1 association with Account. (Attachment 2) Pros: Instead of storing balance information in the Balance entity, I could store the total points and available points directly in the Profile entity. Simpler structure, potentially better for performance for OQLs. And reporting pages. Cons: Messages would need to associate with multiple Profile entities, which goes against the modular design. However, given its simplicity, this might be an acceptable trade-off. 3) Message → Account (1–*) Relations: Messages are directly associated with Account. Pros: Since messages are actually sent by users, associating them with Account makes sense. Cons: Would require storing the point information in Account, whereas I would prefer to keep it in Profile. Which approach would you consider the best practice in this scenario?   (Attachment 1)   (Attachment 2)
asked
1 answers
1

Even though 15K user is not much; in my opinion option 1 is not a good option because it is not semanticly correct. Messages don’t conceptually belong to balances.

 

Messages belonging to profile or account is more reasonable. Both of these entities represent the real user and messages sent / to by user makes sense. If you would like this messaging module modular together with profile (I mean both of those modules to be re-used inanother application), relating the messages to profile is a very good option. If you would like messages module totally independent from profile (ie if you intend to use inanother application where you may not have the profile module) you can relate it to account.

 

In my opinion, relating messages to profile is more reasonble. If you related messages to account and in another application if an account might have multiple profiles (ie:  user has separate characters, roles, or app presences) messages might lose their context: you can’t tell which profile sent/received message without keeping extra information.

 

Lastly, based on messages releation (profile or account), you can keep the balance information in that selected entity as well. I think keeping balance might not be required unless you intend to keep a detailed accountant like history on the balance.

answered