33

I've been thinking about how to implement the badge feature similar to SO's on a new website. What is the best way to store criteria for badges?

Two ideas:

  • All code
  • 'Second system' - create a meta architecture for defining badges and their criteria. Store some info in the database and have code query it to figure out the badges and their criteria.

Are there better ways?

Ryan Doherty
  • 37,071
  • 3
  • 51
  • 62

2 Answers2

40

Rules.

You create events in the system, and use rules within an event stream processor.

Specifically, say you have a badge "made 10 posts". You don't run "select count(*) from posts where user = :user" for every post. Rather, you have a simple rule that watches each post come by, and "count them", storing the rules state in the user profile.

That way "made 10 posts" is as cheap as "made 1,000,000" posts.

This also makes the system much more extensible.

Will Hartung
  • 107,347
  • 19
  • 121
  • 195
  • 10
    If you go this route, be careful of the cases when you add a new badge and need to analyze what existing users should have already earned it. – Doug McClean Feb 07 '09 at 02:08
  • Yes, absolutely a downside of the system, but still its more flexible and scalable as (typically) adding new badges happens far less than testing and awarding them. – Will Hartung Feb 07 '09 at 02:11
  • So how would you handle adding badges down the road? Let 's say I have a new badge like the "woot" badge that SO added. How would you make it retroactive? – Micah Jun 24 '09 at 13:41
  • 2
    You would need to have some mechanism to rerun the event history data to accumulate the statistics necessary for your new badge and bring it up to date. – Will Hartung Jun 24 '09 at 20:37
  • Back-filling badges is a major flaw of this approach. Basically the answer is that you have to write a cron job (likely pure SQL) anyways which contains the rule logic/criteria - so why not just write the cron to begin with and skip the (admittedly fancier) event stream processor? – MikeMurko Oct 25 '12 at 15:09
  • @MikeMurko: It all depends on how responsive you want your badges to be announced, how big your data sets are, etc. – Will Hartung Oct 25 '12 at 16:55
  • Agreed. A job-based approach isn't as responsive. I was speaking more about the necessity of a job when filling in old data (i.e. when you create a new badge, or implementing this system for the first time on an existing product). I guess you could simulate events (in sequence) and run them through your ESP ... but that might be easier said than done. – MikeMurko Oct 25 '12 at 17:35
18

I agree with Will on this one.

Create "events" over the pages so every time an event happens ie. a user deletes a post, it will query the event module with the event, lets say, EVENT_USER_DELETE_POST and then you can select that event and build a query based on it. You can then decide if a badge is awarded or not.

This will keep the two logics seperate and keep a modular design. It should be very easy to implement this way.

The only downside is that if the event was not "captured" then a user may well have earned a badge criteria but it has not yet been rewarded. However, this should never occur. The only situation I can think of is if the database is manipulated manually.

Gary Green
  • 20,931
  • 6
  • 45
  • 74