I am designing an application where users message one another privately, and may send messages to any Entity in the database (an Entity may not have a user account yet, it is a professional database). I am not sure how to best design the database and the API to allow messaging unregistered users. The application should remain secure, and data only accessed by those with correct permissions.

Messages sent to persons without user accounts serve as an invitation. The invited person should be able to view the message, act on it, and complete the user registration upon receiving an InviteMessage.

In simple terms, I have:

    misc user fields (email, pw, dateJoined)

Entity (large professional dataset):
   user->User (may be null) 

   messageContent, other fields.....


I plan to alert the user when selecting a recipient that is not registered yet, and inform that he may send the message as an invitation by providing email, phone where we can send the invitation.

Invitations will have a unique, one-time-use URL, e.g. uuid.uuid4(). When accessed, the invitee will see the InviteMessage and details about completing his/her registration profile.

When registration is complete, InviteMessage details to a new instance of UserMessage (to not lose their data), and assign it to the newly created User.

The ability to interact with and invite persons who do not yet have accounts is a key feature of the application, and it seems better to separate the invitation from the private, app messages (easier to keep functionality separate, better if data model changes).

  • Is this a reasonable, good design?
  • If not, what would you suggest?
  • Do you have any improvements?
  • Am I correct to choose to create a separate endpoint for creating invitations via the API?

1 Answer 1


If a message can be sent to any Entity, it would make more sense to associate the message with the receiving Entity rather than with the user. If you do that, you don't need to distinguish between invitations and normal messages; instead, you can write the invitation-specific data in an own table:

     misc user fields

     user -> User (nullable)

     sender -> User
     recipient -> Entity

     content -> UserMessage
     inviteePhone (aren't these two field part of Entity?)

This increases maintainability: If you ever want to add an additional field to UserMessage you'd have to also change InviteMessage and the code copying an InviteMessage to a UserMessage with your approach.

Moreover, assume that an Entity has received multiple invitations. You'd want persist all of them when a new user account is created. This is also easier if you don't need to copy the message (just delete all Invitations of the Entity's messages).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.