rules-framework
rules-framework copied to clipboard
Add caching capabilities with in-memory cache
Purpose
Create caching functionality for rules fetched from data source. Implement first cache provider in-memory.
Main functionalities
Extend Rules.Framework functionalities by adding following cache behavior:
- Cache response from rules data source.
- Cache response from specific operations - optionally activated if users desire so.
- Cache invalidation of specific sets of cached values.
Proposal
Perform changes to selected points:
- Cache response from rules data source - with cache key by content type and dates interval used to fetch from rules data source.
- e.g. If one tries to match one rule for "ContenType1" on date 2021-11-28,
RulesEngine
will ask toIRulesDataSource
the collection of rules active for "ContenType1" between 2021-11-28 (limit inclusive) and 2021-11-29 (limit exclusive). When this happens and caching is active, result will be stored on cache with key composed of "ContenType1", 2021-11-28 and 2021-11-29. - If a request is placed to rules data source that generates a given cache key, and that cache key has value on cache provider, stored value must be returned as response from rules data source.
- e.g. If one tries to match one rule for "ContenType1" on date 2021-11-28,
- Cache response from specific operations of
RulesEngine
-MatchOneAsync(...)
,MatchManyAsync(...)
,SearchAsync(...)
- considering conditions:- Generate a unique hash from operations parameter values.
- Register, per each operation, the requests made with same hash for last X minutes.
- Should be a configurable value?
- Cache response of operation hashes with request counters superior to defined thresholds
- Have a threshold based on absolute number of requests - configurable.
- Have a threshold based on the percentage of requests (requests made for a specific operation hash vs. requests made for all operation hashes) - configurable.
- Return cached response when criteria of thresholds is matched.
- Implement mechanisms to ensure cache invalidation.
- Always use a sliding window, where older requests tend to leave statistic on a cleanup activity and new requests are registered as they are done.
- 2 alternatives to assure cache consistency: cached value max TTL or cache invalidation on operations that cause changes to rules data source.
- Feature is optional, meaning, adding caching capabilities does not imply caching operation responses - needs to be explicitly configured to do so.
- Invalidate all cached values for any change done to a content type (add/update rules).
- Consider invalidating only a subset if possible, meaning, if changed rule/rules only affect evaluation from date A to date B, only cached values between A and B need to be invalidated, remaining ones are still valid.
Create cache abstractions to allow:
- Setting a new cached value by cache key.
- Invalidate a cached value by cache key.
- Verify if a cache key has value.
And implement a cache specific implementation for in-memory, considering the abstractions above and grouping cached values by content type.
NOTE: proposal is open to debate and actual implementation plan is to be added later here.