title: Building a notification system
body: <p>I am at the start of building a Facebook style notification system for our page (social gaming type) and I'm now researching what would be the best way to design such system. I'm not interested in how to push notifications to the user or anything like that (for now even). I am researching how to build the system on the server (how to store notifications, where to store them, how to fetch them etc...).</p>
  
  <p>So ... some requirements that we have:</p>
  
  <ul>
  <li>at peak times we have about 1k concurrent logged-in users (and many more guests, but they don't matter here as they will not have notifications) that will generate many events</li>
  <li>there will be different types of notifications (user A has added you as a friend, user B has commented on your profile, user C has liked your image, user D has beaten you on game X, ...)</li>
  <li>most events will generate 1 notification for 1 user (user X has liked your image), but there will be cases where one event will generate many notifications (it's user Y's birthday for instance)</li>
  <li>notifications should be grouped together; if for instance four different users like some image, the owner of that image should get one notification stating that four users have liked the image and not four separate notifications (just like FB does)</li>
  </ul>
  
  <p>OK so what I was thinking is that I should create some sort of queue where I would store events when they happen. Then I would have a background job (<a href="http://gearman.org/">gearman</a>?) that would look at that queue and generate notifications based on those events. This job would then store notifications in the database for each user (so if an event affects 10 users, there would be 10 separate notifications). Then when user would open a page with the list of notifications I would read all those notifications for him (we ware thinking to limiting this to 100 latest notifications) and group them together and then finally display them.</p>
  
  <p>Things I'm concerned about with this approach:</p>
  
  <ul>
  <li>complex as hell :)</li>
  <li>is database the best storage here (we are using MySQL) or should I use something else (redis seems like a good fit too)</li>
  <li>what should I store as a notification? user ID, user ID who initiated the event, type of event (so that I can group them and display appropriate text) but then I kinda don't know how to store the actual data of the notification (for instance URL&amp;title of the image that was liked). Should I just "bake" that info when I generate the notification, or should I store the ID of the record (image, profile, ...) being affected and pull the info out of the DB when displaying the notification.</li>
  <li>performance should be OK here, even if I have to process 100 notifications on-the-fly when displaying the notifications page</li>
  <li>possible performance problem on every request because I would have to display the number of unread notifications to the user (which could be a problem in its own since I would group notifications together). This could be avoided though if I generated the view of notifications  (where they are grouped) in the background and not on-the-fly</li>
  </ul>
  
  <p>So what do you think about my proposed solution and my concerns? Please comment if you think I should mention anything else that would be relevant here.</p>
  
  <p>Oh, we are using PHP for our page, but that shouldn't be a big factor here I think.</p>