The outline of an automated monetization of recognition rewards

Problem Statement: Employees in an organization work from home and rely on applications like Slack to remain connected to the workplace. They use emojis to recognize each other’s hard work. Employers would like to leverage this peer recognition to be automatically translated to monetary rewards for the recipients. This should not require any extra action or change in the habit of the recipient in their daily routine.  

Solution: Badges and emojis are staple forms of communication language between team members of an organization. They are immediate, informal, and peer-reviewed forms of recognition. Up until now, any mechanism of translating peer recognition to rewards used to involve a laborious process disrupting both the sender and the receiver's routine which tends to elevate the barrier to rewards and their receipt. The following mechanism introduces inline automation to translate the recognition events to reward points which are eventually cut out to gift cards and sent to the recipients.  

This automation includes a sender and a receiver side.  The sender introduces a bot user to all the monitored Slack channels. This bot user subscribes to an event loop using an Event API available from Slack and follows the event-driven sequence. A user posts an emoji for recognition of another user and an event of type ‘reaction_added’ along with attributes such as ‘item_user’ who is the recipient of the recognition. The bot user receives the event and responds within three seconds. The event loop guarantees to post the event with grace, security, respect, and retry.  The bot user handles each event notification with a light-weight technical implementation that treats each event to be of equal value in terms of reward points. Each event notification is translated to a reward point creation request in a reward point accumulation service that maintains a ledger of owner and reward points.   

The automation on the receiver side targets the redeeming of the reward points accumulated by a user. Each distinct recipient receives an aggregation of the reward points accumulated periodically. When the reward points exceed a threshold, an eGift card from a major online retailer is cut out using the eGifter API. The code generated for the eGift card from the redeemed reward points is mailed out to the email address retrieved from Slack for that recipient.  Since the codes are dynamic and the emails are delivered to the recipient’s email inbox, the sender and receiver take no additional actions for getting reward points.   

Since the event metadata gives enough visibility on the policies associated with qualifying an event to the reward points creation such as maximum possible rewards from one user to another in a day, the reward points generation can be controlled and free from malpractice.  

The implementation for this monetization of an automated peer recognition system is outlined here: https://github.com/ravibeta/RewardPoints  

Further reading on scaling up these services to arbitrary usage and size of an organization is included here.  

 

User Identity Integration with Organizations for reward points services

The reward points mean nothing without an owner. This person is most likely an employee of a business partnering with the reward points accumulation and redeeming service. The service delivers a comprehensive one-stop-shop for reward points and recognition programs. This makes it easy and consistent for businesses to follow and sign up for the program. This makes the reward point services truly global and offered as a software-as-a-service. 
The identity and Access Management is a critical requirement for this service without which the owner reference cannot be resolved. But this identity and access management does not need to be rewritten as part of the services offering. An identity cloud is a good foundation for IAM integration and existing membership providers across participating businesses can safely be resolved with this solution. 
The use of a leading IAM provider for Identity cloud also helps with the integration of on-premise integration of applications.  The translation of the owner to the owner_id required by the rewards service is automatically resolved by referencing the identifier issued by the cloud IAM. Since the IAM is consistent and accurate, the mappings are direct and accurate. The user does not need to sign in to generate the owner_id. They can be resolved with the integration of the membership provider which is on-premise for the organization such as with Active Directory integration to the identity cloud. Since the integration of different applications for enterprises is expected to be integrated with the Active Directory or IAM provider, the identity cloud can be considered as global for this purpose. The identities from different organizations will require to be isolated from each other in the identity cloud. The same convention can be leveraged by the reward points services. 

The difference between a B2B and a B2C reward points service stands out when the user does not have to register into yet another portal albeit for rewards. With the integration of enterprise-wide IAM to an identity cloud provider and the availability of attributes via SAML, the mapping of reward points to rewards becomes automatic. Together with the automatic collection of user activities from a variety of enterprise deployed applications, the reward points become increasingly significant and appealing to use. 

We assume the reward points balance is maintained accurately in the data layer. The service accumulating and redeeming from this balance update the same source of truth. Both the services recognize the same owner for the reward points because they use the same identity cloud. The redeeming service focuses on making one or more debits against the reward points balance. As long as the reward points store consistently handles the debit and the credit, the granularity of debits does not matter to the debits against the balance.  

This redeeming service simply creates, updates, and deletes a debit entry record in the ledger holding the reward points as long as the rewards added to the cart by the cart service can be honored. This is a simple online transaction processing system that brings the database guarantees to the ledger.   

The database should have change data capture and some form of audit trail. This is essential to the redeeming service because it prevents the detection of misuse. A debit should only be processed when all the security measures have passed.  

The redeeming service supports use-cases for reversal. In such cases, the entry may simply be removed from the ledger. The guarantees from the ledger are sufficient to ensure consistency. In the long run with expanded use cases, reward points may enable multiple stores and their carts to use the same service. In such a case, the microservice architecture for redeeming reward points will be helpful.   

The redeeming service can be simply written as a model-view-controller with the debit as the model. The controller has actions specific to list, create, update, delete, and get by id.  The list action will support ordered and paged entries as well as query parameters. The views are for administrative purposes.  

This session identifier is usually obtained as a hash of the session cookie. And is provided by the authentication and authorization server.  The session identifier can be requested as part of the login process or by a separate API Call to a session endpoint. An active session removes the need to re-authenticate. It provides a familiar end-user experience and functionality. The session can also be used with user-agent features or extensions to assist with authentication such as password-manager or 2-factor device reader.  

There are certain options other than build-your-own service. These options provide the ability to distribute a debit to multiple stores. For example, the Stripe Connect API allows the routing of reward points like payments between the owner and the recipients. Since the participating stores fulfill these orders independently, the reward points redeeming service concerns itself only with owners and their reward points. 

Writing debit and credit as a service

 

Problem statement:  How should a reward points redeeming service be implemented given that the debit and credit are typically occurring on separate services? 

Solution: We assume the reward points balance is maintained accurately in the data layer. The service accumulating and redeeming from this balance update the same source of truth. Both the services recognize the same owner for the reward points because they use the same identity cloud. The redeeming service focuses on making one or more debits against the reward points balance. As long as the reward points store consistently handles the debit and the credit, the granularity of debits does not matter to the debits against the balance.  

This redeeming service simply creates, updates, and deletes a debit entry record in the ledger holding the reward points as long as the rewards added to the cart by the cart service can be honored. This is a simple online transaction processing system that brings the database guarantees to the ledger.   

The database should have change data capture and some form of audit trail. This is essential to the redeeming service because it prevents the detection of misuse. A debit should only be processed when all the security measures have passed.  

The redeeming service supports use-cases for reversal. In such cases, the entry may simply be removed from the ledger. The guarantees from the ledger are sufficient to ensure consistency. In the long run with expanded use cases, reward points may enable multiple stores and their carts to use the same service. In such a case, the microservice architecture for redeeming reward points will be helpful.   

The redeeming service can be simply written as a model-view-controller with the debit as the model. The controller has actions specific to list, create, update, delete, and get by id.  The list action will support ordered and paged entries as well as query parameters. The views are for administrative purposes.  

This session identifier is usually obtained as a hash of the session cookie. And is provided by the authentication and authorization server.  The session identifier can be requested as part of the login process or by a separate API Call to a session endpoint. An active session removes the need to re-authenticate. It provides a familiar end-user experience and functionality. The session can also be used with user-agent features or extensions to assist with authentication such as password-manager or 2-factor device reader.  

There are certain options other than build-your-own service. These options provide the ability to distribute a debit to multiple stores. For example, the Stripe Connect API allows the routing of reward points like payments between the owner and the recipients. Since the participating stores fulfill these orders independently, the reward points redeeming service concerns itself only with owners and their reward points. 

 

Network Engineering continued ...

 This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html 

305. Random writes perform just as well as sequential writes on SSD as long as the data are comparable. If the data size is small and the random writes are numerous, it may affect performance. 

306. 
     

306. The use of garbage collector sometimes interferes with the performance of the networking server. The garbage collector has to be tuned for the kind of workloads. 

307. 
     

307. In Solid State Drives as per descriptions online, there is a garbage collection process inside the SSD controller which resets dirty pages into renewed pages that can take the writes. It is important to know under which conditions the garbage collection might degrade performance. In the case of SSD, a continuous workload on small random writes puts a lot of work on the garbage collection. 

308. 
     

308. A garbage collector will find it easier to collect aged data by levels. If there are generations in the pages to be reclaimed, it splits the work for the garbage collector so that the application operations can continue to work well. 

309. 
     

309. Similarly, aggregated and large pages are easier for the garbage collector to collect rather than multiple spatially and temporally spread out pages If the pages can be bundled or allocated in clusters, it will signal the garbage collector to free them up at once when they are marked 

310. 
     

310. Among the customizations for garbage collector, it is helpful to see which garbage collector is being worked the most. The garbage collector closer to the application has far more leverage in the allocations and deallocations than something downstream. 

Network engineering continued ...

300. This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html 

301. 
     

302. Disks compete not only with other disks but also with other forms of storage such as Solid-State Drives. Consequently, disks tend to become cheaper, capable, and smarter in their operations with added value in emerging and traditional usages. Cloud Storage costs have been said to follow a trend that asymptotically reaches zero with the current price today at about 1c per GigaByte per month for cold storage. The average cost per GigaByte per drive has come down by half from 4c per GigaByte between 2013 and 2018. 

303. 
     

301. Solid State Drives are considered replacements for memory, L1, and L2 cache with added benefits. This may not necessarily be true. It is storage even if it does wear out. Consequently, programming should be more mindful of the reads and writes to data and if they are random, store those data structures on the SSD drives. 

302. 
     

302. The use of sequential data structures is very common in storage engineering. While some components go to great length to make their read and write access sequential, other components may simplify their design by storing on SSD. 

303. 
     

303. Reads and writes are aligned on page size on Solid-State Drives while erasures are on a block level. Consequently, data organized in data structures can leverage these criteria for reading some or all at once. If we are writing less than a page more frequently, we are not making good usage of the SSD. We can use buffering to aggregate writes. 

304. 
     

304. The internal caching and readahead mechanism in the SSD controller prefer long continuous reads and writes rather than simultaneous multiple reads and writes and performs them in one large chunk. This means we open up iterations and aggregate reads and writes to do them all together