CODEWITHSUNDEEP
design-patternsdatabase-design
Clement Herreman
Clement Herreman

Reputation: 10536

Design pattern : notification system

I'm working on a website that will use features of social networking (like facebook for example).

I would like to implement a notification system which shows stuff like "X added you as a friend", "Y invite you to the party", "Z has taken the lastest quizz"... and i don't know how to do.

I wonder what is the best solution :

A dedicated table "notification". I add rows in this table everytime something that rise a notification happend (friend adding, quizz answering, etc.). The table "notification" has fields that contains different information, according to what kind of notification is added to the table.

Good : easy to code, separation between notification feature and "normal" features, not too much resources-consuming when i need to read the table.

Bad : Notification table will grow probably very big (i think I will add 10k rows/day in the table), "duplicated" information : informations in the notification table can be found in all other table using date/list/whatever comparison.

Everytime i need to show the notification list or the show how much new notifications there are, I look to all the concerned table, compare date/etc to know if something new happened since the last time the user checked the notification.

Good : Not a too big table compared to solution 1, no "redundancy" of information.

Bad : I am affraid because of the number of user (~1k+), it make the server explode because it is resource/time consuming, little harder to code/maintain.

Can you please tell me what you think the better and why, or do you have a solution i didn't imagined ?

Thanks =)

Edit : Let's say i use a really basic DB design : users have friends, can do quizzes.

1 table for user list, quizz list,

1 table quizz<->user relation,

1 table user<->user for friendship.

Everytime a user visit his own profile, he can see what happened : new quizz<->user relation, new user<->user relation, etc. How would you design a notification like that ?

Upvotes: 43

Views: 22341

Answers (5)

Lubdhak
Lubdhak

Reputation: 116

what i did was put up a dedicated service to store following data :

  • recipent_id
  • actor_id
  • html_msg
  • meta_data
  • if_seen
  • timestamp

And a Socket Push to UI if user is Online

Upvotes: 0

Md Rahatur Rahman
Md Rahatur Rahman

Reputation: 3244

Services like AWS and Azure is providing notification frameworks. If you use any of those then you may not need to worry about the table structures. All you need is to trigger the notification from different point of your application.

For example when a user likes something from another user, then your application can trigger a send event (can be sent to thousands of users with a single API call). The API will store and forward the record to the destination user or users.

This is working good for us.

Hope this helps others looking for similar solutions.

Upvotes: -1

Salih Erikci
Salih Erikci

Reputation: 5087

I suggest using plain notifications. No notification-type or something else.

Notifications
-id
-message
-href (Link to go when user clicks the notification)
-receiverUser
-date

Example usage: John(34) liked a photo of Mary(47). (We are sending notification to Mary) 

INSERT INTO Notifications(message,href,receiverUser, date) VALUES ('John liked your photo', 'link of the photo', 47, 01.11.2014)

Upvotes: -1

AlexC
AlexC

Reputation: 1415

Create a system queue, each message added to this queue has a list of "consumers" and the content. The main message pump processes each message and sends the message to all consumers.

Lets say 2 people befriend each other. You add a message to the main system queue that A is friends with B and consumers are both A and B. When your message "pump" (processor) sees this message it adds it to the queue of A and the queue of B. So now user A and user B have a new message that they are friends. In turn each user has a message processor, so when it sees a message called "I am friends with [someone]" it processes this as add a new entry to the "wall" visible to friends of A that "A is friends with B", etc.

This is overly simplistic but hopefully shows how message queues can be used for this (very similar system is used as the windows UI framework) so there is already an existing example and there are plenty of synchonized message queue patterns you can use.

Rest is up to you to design.

Upvotes: 23

Aiden Bell
Aiden Bell

Reputation: 28386

Really this falls under the how do I design a car? type question category ...

The implementation depends on the design, where it will go in future and the environment you will implement in. You might choose a twitter-esque implementation, a SAN-backed system of XML, Relational Databases, Hadoop and tons of others.

A good knowledge of web technologies, experience, trial and error is the only way you can design any feature with certainty that you are doing it is the right(ish) way.

What are your performance needs? Traffic levels? User requirements? Do you want to distribute later (through webhooks for example?).

Your question needs to be more specific.

I personally would have a table of "notification-types" acting like an enum ... and then a user<>notification table handling the relationship between notification and user.

With some good coding, you can splice the user<>notification table across many servers and key on userid or similar ... and replicate the types table across each of those nodes for local cache/reference. Something like that.

Upvotes: 14

Related Questions