This RFC proposes ways to develop a feature that updates the RDS user's server nickname during and after OOO. The primary focus is to develop the feature in the most efficient way that reduces the level of human interaction required to update server nickname. The purpose of this document is to gather feedback and approval from stakeholders before proceeding with the development.
2. Objectives
With this feature:
Users' RDS server nickname should be updated and reflect their status with minimal human intervention.
Frequently provide a medium to update the RDS server nickname with either the dates (when user on OOO) or without the dates (when user's OOO ends).
3. Scope
The OOO server nickname feature will have the following changes:
OOO dates for the user should be added to the nickname when
Current status of the user is OOO
The future OOO of the user is three days away
OOO dates for the user should be removed from the nickname when the dates have exceeded
4. Proposed Solution
The following solutions have been proposed for updating the OOO nickname:
1. Batch Update
A batch update can be used which when called frequently would update the RDS users' nickname based on the current or future status.
Pros
Faster development
Easy to implement and execute the command
Cons
Human intervention heavily required to run the batch update in frequent intervals
Run the update every time on all existing user status documents. This would lead to updating of the same users' nickname multiple times
2. Cron Job
A cron job that updates the RDS users' nickname can be scheduled in regular intervals. The scheduled job would invoke the appropriate batch update to change the nickname.
Pros:
Minimum human intervention needed
Need not run the update every time on all existing user status documents. Can only execute the job on the documents that updated after the previous job's timestamp.
Cons:
Increase in latency since this process involves multiple API calls.
Require the timestamp of the last successfully executed job that updated the nicknames. This is to ensure that the same, unchanged set of users' status are not updated.
More development time and config needed
2.1. Using KV Stores from Cloudflare
Key-Value (KV) store namespaces from Cloudflare can be used to store the value of the timestamp during which the last cron job executed.
Pros:
Easy to access the namespace via cron job code
Access to API which can be invoked from website-backend as well
Cons:
Setup and config steps to create namespaces and use the API is not a straightforward process.
If in the near future, another platform would be used instead of Cloudflare for cron jobs, then an alternate platform for KV stores has to be figured
5. Conclusion
This RFC outlines the proposal for the development of the feature to update the RDS users' server nickname The feature aims to adopt the most efficient method to update a users' RDS nickname.
Your feedback and comments on this RFC are greatly appreciated.
1. Introduction
This RFC proposes ways to develop a feature that updates the RDS user's server nickname during and after OOO. The primary focus is to develop the feature in the most efficient way that reduces the level of human interaction required to update server nickname. The purpose of this document is to gather feedback and approval from stakeholders before proceeding with the development.
2. Objectives
With this feature:
3. Scope
The OOO server nickname feature will have the following changes:
4. Proposed Solution
The following solutions have been proposed for updating the OOO nickname:
1. Batch Update
2. Cron Job
2.1. Using KV Stores from Cloudflare
5. Conclusion
This RFC outlines the proposal for the development of the feature to update the RDS users' server nickname The feature aims to adopt the most efficient method to update a users' RDS nickname.
Your feedback and comments on this RFC are greatly appreciated.