rules-framework icon indicating copy to clipboard operation
rules-framework copied to clipboard

Add caching capabilities with in-memory cache

Open luispfgarces opened this issue 3 years ago • 0 comments

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 to IRulesDataSource 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.
  • 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.

luispfgarces avatar Nov 28 '21 15:11 luispfgarces