The design of reward point service push notifications:

Introductions: Reward points are a form of currency. If we have an account, the collection of reward points accumulated is a thrill to watch on any mobile device as appreciations come from individuals and businesses for various monitored activities. This article explores the design of a notification service for sending notifications on reward points to millions of users.

Description:  we discussed  three considerations to the update of reward points which include the following: 1. data model, 2. push ranking and 3. push release. The data model is simple for this reward points service. It consists of a reward point information data structure that has additional attributes such as the last updated timestamp, the last few activities that generated the update and the redeemable options if any. We focus on just the balance, the timestamp and activities for the push object. The activities are ranked not just on chronological activity but also on criteria set for ranking based on weighted features of the reward points. The intimacy of the users who send the reward points can also be encoded in the central repository so that it can be weighed into the ranking for the activities that need to be sent. We could simply the update for the notifications if we excluded the activities because there can be millions of users and we would not be selective both on the push side from the server and on the pull side from the mobile devices. Instead, we can consider the updates to be tackled independently for the account balance and for the activities that generate the updates. When there are only a few hundreds of users, the release may be simpler but when there are millions of users, the updates must be economical and must be handled with selectivity.  The account balance is merely a data artifact, but its synchronization can be represented in the control plane with the help of a resource. This resource can get out of sync as the data is updated but the resource representation in the control plane allows it to be synchronized in the target device. The activity can be triggered both by the mobile device that wants to check in as well as the server that wants to push the notifications to the user. The synchronization of resources in control plane is well established with orchestration frameworks that take away the overhead of writing synchronization service. Instead, all data activities can be monitored to trigger control plane notifications.  The operational engineering aspects of the reward points services can be maintained by this state orchestration framework if we have only one resource to be decided. The clients can choose to check-in at selective times and the server can be selective about which clients to update. When the push objects consist of activities, there are options to reduce the number of connections to the central repository by denormalizing the data even if there is some redundancy. The selection of activities can be determined by improvements to the ranking algorithm. Core indicators such as grantor stickiness, retention rate and advertising revenue can determine whether the ranking algorithms is behaving correctly. The resource updates can be sent immediately to the device which reduces the impact of the ranking algorithm. Similarly, the resource updates can be pulled only when the device wakes up. This optimizes the write update because the data does not need to be sent out. Both methods work well in certain situations. The process of sending data to all devices is a broadcast operation. This can happen in both writing as well as loading. It can be made selective as well. The broadcast can be limited during both pull and push. Disabling the writes to all devices can significantly reduce the cost. Other devices can load these updates only when reading. It is also helpful to keep track of which devices are active over a period so that only those devices get preference.

The control plane resource reconciliation can be done with a controller pattern which tracks at least one  resource type. These objects have a spec field that represents the desired state. The actual reward point is the current state. The controller is a control loop that watches for the state of the resource and then makes, or request changes where needed. There can be several controllers depending on resource types. Each controller tries to move the current state to the desired state by reading the spec field. The controller might carry out the action itself or it will relay a request to the API server. The control plane resource object can be created, updated or deleted just like any other resource with representational state transfer api design. The controller can set additional states on the resource such as marking it as finished.

Conclusion: The Reward points services requires only a resource representation in the control plane for the synchronization to span any number of devices.