Architecture Tactics ‐ Availability - SENG-350-2024-fall/Team-11 GitHub Wiki
Availability Tactic: Timestamp as an Availability Tactic
1. Questions for Assessment:
- Does the data remain accessible even after the user closes the application or refreshes the page?
- Can users access their evaluation history without an internet connection?
- Are each user's recommendations isolated from others to maintain privacy?
2. Selected Architecture Tactic:
Timestamp as an Availability Tactic: Utilizing timestamps to log recommendations allows users to reference previous evaluations without impacting the system's availability for others.
3. Manifestation in Design:
A JavaScript array, evaluationHistory, is implemented to store each user's recommendations along with their respective timestamps upon evaluation. This structure ensures that every recommendation is tied to the time it was made. The data remains accessible only to the user who made the evaluation, thereby upholding privacy and preventing interference with other users’ data.
4. Testing Plan:
Observation: After integrating the timestamp mechanism, I will test the functionality by submitting multiple evaluations. I will observe if the recommendations and their corresponding timestamps are displayed accurately for the user. I will also verify that the history is correct and that users can only access their own recommendations.
Availability Tactic: Retry as an Availability Tactic
1. Questions for assessment:
- How does the retry tactic impact user experience during retries?
- Does the user receive clear feedback on the success or failure of prescription submission, particularly during retries?
2. Selected Architecture Tactic:
Retry as an Availability tactic: Implementing a retry mechanism improves the reliability of the prescription submission process by allowing multiple attempts to complete the operation, in case of transient failures. This ensures that users are not negatively affected by temporary issues such as database unavailability.
3. Manifestation in Design:
The retry mechanism is built into the submitPrescription function. Specifically:
- Asynchronous execution: enables use of await for handling promises
- Retry logic: a retry function is created, which accepts a function to execute and implements logic for retries. It attempts to call the provided function multiple times with a delay if errors occur.
- User Feedback: Upon submission, the user is informed of the result through the result div. If successful, a confirmation message is displayed. If all retries fail, an error message is shown.
4. Testing Plan
To test the functionality of the retry mechanism, I will simulate successful and failed submission attempts and ensure retry mechanism activates, and correct error messages are shown on failure.
Availability Tactic: Condition Monitoring as an Availability Tactic
1. Criterion for assessment:
- Response time from database to website.
- Number of requests completed per second versus number of requests made per second
- Number of failed requests / total requests.
- Asserting total uptime. A reasonable number would be 2 nines, as this is a healthcare system. We should aim for one nine for now.
- Database query times.
- Regular log checks to ensure few or no outlier logs (exact number of acceptable outliers TBD).
2. Selected Architecture Tactic:
Condition Monitoring as an Availability Tactic: Condition Monitoring is closely related to the Internet of Things (IoT), in which a service provider continually ensures the infrastructure the software system replies upon is available and meeting reasonable uptime, request times, etc.
3. Manifestation in Design:
We use condition monitoring to check our access to our remote server and database at many checkpoints through the code, most notably when retrieving data, but also when checking when users are logged in or not, when accessing a page with confidential information. This can be improved upon by setting up continual checks every X minutes to ensure the database and hosting servers are still running correctly. How frequently has yet to be determined, and would be a group discussion before reaching a final number.
4. Testing Plan
Through a series of tests, benchmarked and stored now and later. If the test times and results are consistent or improve, we will be meeting our targets. However, if test times decrease, we must improve our services.
These tests will be outlined by list in criterion above (section 1). They should include timed data, as well as total number of requests performed per time period, average requests per second, highest requests per second, and how those different attributes contribute to the criterion metrics (ie, at 300 requests per second, does the server stop responding? If not, at how many rps does it fail? Is this a reasonable load to expect?)
Availability Tactic: Removal from service as an Availability Tactic
1. Questions for Assessment:
- What impact does removing certain components have on the functionality of other parts of the system?
- How does the system maintain a smooth user experience when some components are unavailable?
2. Selected Architecture Tactic:
Removal from service as an Availability Tactic: The removal from service tactic allows for testing the system’s handling of component failures and evaluating the user experience under partial outages. This approach also verifies the effectiveness of failover strategies and backup mechanisms, ensuring that essential functions remain accessible, even when some services are offline.
3. Manifestation in Design:
The removal from services is controlled through flags and toggle functions, which dynamically adjust the availability of various components. These flags serve as availability switches, enabling the simulation of service removal or restoration. Each service has an associated toggle function that changes the flag status to either activate or deactivate the service.
4. Testing Plan:
The testing process involves using toggle functions to adjust service availability by changing flag states. This approach enables assessment of the overall system’s performance and behavior when certain services are temporarily unavailable.
Availability Tactic: Redundant spare as an Availability Tactic
1. Questions for assessment:
- How is the user's experience affected in the loss of data in the system?
- Will there be any downtime if a part of the system fails?
2. Selected Architecture Tactic:
Redundant spare as an Availability tactic: The redundant spare tactic allows for a failsafe for all the important data stored by the system. If anything were to go wrong, the redundant spare could be used as a backup to ensure no information is lost.
3. Manifestation in Design:
The redundant spare is implemented as two separate clusters in AWS to store the information in our database. One is implemented as a primary cluster where read and writes can be performed. The secondary cluster is used as a read only spare for the primary cluster which mirrors any changes made to the primary cluster to uphold consistency. The two clusters are stored in different servers, and if an issue occurs on one of the clusters, the other can be used to restore data without any loss of service. In addition, snapshots will be made regularly for the database so that if any unintended change is made, data can be restored to a previous version.
4. Testing plan:
To test this tactic, I will make some unwanted changes to the primary database, corrupting some test entries, and make sure that a backup can be restored either from previous snapshots, or from the secondary cluster.