Title: Optimizing Rule Result Caching via Rule List Publication
As a Rule Processor (RP) user,
I want to optimize the caching process of rule results in the Typology Processor (TP),
So that the redundant caching of rule results in Redis for multiple typologies is eliminated, reducing unnecessary Redis requests and improving efficiency.
Scenario: Efficient Rule Result Caching
Given that the Rule Processor (RP) completes its processing and generates rule results.
When the Rule Processor (RP) finishes processing a rule,
Then the Typology Processor (TP) currently sends each rule result individually to every configured typology.
However, this results in each typology independently caching the same rule result object in Redis.
This leads to inefficiency, causing multiple Redis requests for caching the same rule result across different typologies.
Proposal: Optimize Caching Process
As a resolution, this ticket suggests implementing a change in the process:
Introduction of Rule List Publication: The Typology Processor (TP) will immediately publish a Rule List to Redis as soon as a rule result is received from the Rule Processor (RP).
Aggregate Rules for Typologies: Subsequently, the TP will transmit an aggregated list of rules for processing to each configured typology, instead of sending individual rule results.
Expected Outcome: Improved Efficiency
This enhancement will ensure that each rule result is cached only once in Redis, significantly reducing the number of redundant requests sent to Redis for caching purposes.
Acceptance Criteria:
Rule Processor (RP) transmits rule results to the Typology Processor (TP) as usual.
Typology Processor (TP) immediately publishes a Rule List to Redis upon receiving a rule result.
The TP sends an aggregated list of rules for processing to each configured typology instead of individual rule results.
Verify that each rule result is cached only once in Redis despite multiple typologies configured.
Performance testing to validate the reduction in Redis requests and improved efficiency.
Impact Analysis:
Positive Impact: Significant reduction in Redis requests, improved system efficiency, and optimized resource utilization.
The amount of writes are reduced to exactly Rule Count x Redis writes + 1 delete (which is blocking transactions in Redis), instead of Rules per Typology x Redis writes x 2.
Reads are also reduced in amount, but increased in bandwidth - from reading [typology count] of times and [rule count per typology] in size, reads will now be [rule amount] of times and [rule count] in length.
No Negative Impact:
Conclusion:
This user story aims to streamline the caching process of rule results by introducing a Rule List publication and sending aggregated rules for processing to typologies, reducing the number of requests made to Redis and optimizing system performance.
Title: Optimizing Rule Result Caching via Rule List Publication
As a Rule Processor (RP) user, I want to optimize the caching process of rule results in the Typology Processor (TP), So that the redundant caching of rule results in Redis for multiple typologies is eliminated, reducing unnecessary Redis requests and improving efficiency.
Scenario: Efficient Rule Result Caching
Given that the Rule Processor (RP) completes its processing and generates rule results.
When the Rule Processor (RP) finishes processing a rule,
Then the Typology Processor (TP) currently sends each rule result individually to every configured typology.
However, this results in each typology independently caching the same rule result object in Redis.
This leads to inefficiency, causing multiple Redis requests for caching the same rule result across different typologies.
Proposal: Optimize Caching Process
As a resolution, this ticket suggests implementing a change in the process:
Introduction of Rule List Publication: The Typology Processor (TP) will immediately publish a Rule List to Redis as soon as a rule result is received from the Rule Processor (RP).
Aggregate Rules for Typologies: Subsequently, the TP will transmit an aggregated list of rules for processing to each configured typology, instead of sending individual rule results.
Expected Outcome: Improved Efficiency
This enhancement will ensure that each rule result is cached only once in Redis, significantly reducing the number of redundant requests sent to Redis for caching purposes.
Acceptance Criteria:
Impact Analysis:
Conclusion:
This user story aims to streamline the caching process of rule results by introducing a Rule List publication and sending aggregated rules for processing to typologies, reducing the number of requests made to Redis and optimizing system performance.