Badge - data structure / models?

Question

I'm trying to figure out how one would set up a database and/or model in order to handle various badges. Lets take the Stack Overflow badges as an example. There are different rules for each and some might be just a variable different (like 10 comments vs 100 comments).

My question is how do you set up this type validation/check within an application? Should each badge have its own method?

Answer 1

Being that SO runs off SQL Server, SQL Server Agent Job to run periodically to tabulate statistics. The stored procedure(s) in the job would insert into a badges/etc table when criteria is met.

Triggers would be another option, but their execution can't be delayed for the scope of multiple users.

Answer 2

That is how I would implement it if I need to:

I'll set up some queue manager (there are a lot of such software) and write a broker, that will process the messages from the queue.

Each time any event occurs, such as: You viewed a topic, you edited your comment, you edited your answer, you edited another person answer, you upvoted, etc etc - you collect one more messages, with event description. Yes, it will be really huge amount of messages there.

After you collect that huge amount of messages - you can start a broker that will process messages by schedule or in real time.

With this schema you could extend a broker to as complex badges as you want.

Answer 3

I would imagine some are calculated realtime, while others are calculated in processes that run intermittently.

For example, for the badge that appears when your answer gets 10 upvotes, that could be calculated realtime with little performance hit.

On the other hand, for the badge that checks if you hit the daily reputation cap x number of times, you would probably want to do that as some sort of batch job, since you only check at the end of each day.

The key concern is to keep things running fast. Stack overflow gets thousands (maybe tens of thousands) of questions a day, with probably hundreds of thousands of comments. Anything that is not trivial to calculate should be run in a separate process. It keeps the core functionality tight, limited, and clean, allowing high performance. Running complex calculations in processes outside the core posting system allows you to do so without affecting users' ability to use the site. If a task is sufficiently complex, you can scale horizontally by just running the same process across multiple machines.