Most of the applications have some sort of badging functionality which is used to display certain counts to the users for CTA (Call To Action).
Once the user clicks or acknowledges the counter, the value associated with the counter will need to be reset.
Given a system with large number of users and a large data set, it's not always possible to compute the counter values in real time. Counts in the database world are aggregation operations and would need to perform a whole table scan.
An alternative approach to doing count operation is to keep track of the counts in separate fields/columns in the database. This means that application has to perform two separate operations, one to store the data related to an action and another to increment/decrement/clear the counter fields/columns.
Like explained above, the three main actions associated with the counters are :
1. Increment
2. Decrement - This usually happens when an action is undone or something is deleted.
3. Reset - When user acknowledges the counter.
All the above actions could happen concurrently and be associated with a user. For this reason, all the operations on the counter needs to be atomic otherwise the counter values would be off and not accurate.
A common example for the badging/counter feature is the Facebook notification system.The counters associated with the user are based on the actions performed by other users.
A user can be associated with several other users and many of those other users could be performing the same or different actions at the same time. For example, there could be 3 people sending the user messages and another 4 people sending friend requests.
Fig 1: Facebook Notifications
Given the above behavior of the system, the badging system can be designed as an event driven system. This would make the counter values eventually consistent but will free up the core application from performing any counter related operations such as large scale aggregation operations or slow queries. This also provides an opportunity to setup an isolated database/store for tracking counters separately.
Individual services would generate events which would get listened to by an events processor service. Based on the data in the event, the processor will update the value of counters associated with the user.
Fig 2: Simple Badging/Counter Service Architecture
Here is a simple example of the REDIS HASH data structure which can be used to store the counters associated with the user. Each HASH is associated with a userId and all the counters are tied to the hash as key-value pairs.
Fig 3: Badging Redis Structure