Story: implement cross-cutting caching strategy

[paullatzelsperger]

Feature Request

Various data backends we have ("*stores") should have a caching layer to reduce communication with the actual database and to speed up requests to the connector.

Which Areas Would Be Affected?

All data backends

Why Is the Feature Desired?

The main drivers for this feature request are:

1. access time: keeping certain objects in - and accessing them from - memory will speed up request turnaround times greatly.
2. implementation simplicity: things like filtering and sorting can be implemented in a generic and much easier way when operating on a memory-based collection as opposed to: a database table.

Solution Proposal

I propose devising a caching mechanism with interchangeable eviction strategies, that allow for adapting this to particular needs, and even delegate out to dedicated cache services such as Redis, which may come in handy in clustered environments.
Several implementations could come out-of-the-box:

• write-through: every write hits the cache and the data backend, every read only hits the cache. only suitable for smaller collections
• batch-write ("write back"): similar to write-through, only persists cache periodically.
• ringbuffer: only a certain amount of elements is held in memory and "old" elements get evicted. Eviction could happen due to age or access frequency. Suitable for very large collections, e.g. the AssetIndex.
• shared cache: delegation to e.g. a Redis service. Best for clustered deployments.

Type of Issue

Improvement Story

THIS IS NOT YET READY FOR DEVELOPMENT, NEEDS FURTHER DETAILS

Checklist

• assigned appropriate label?
• Do NOT select a milestone or an assignee!

[github-actions]

This issue is stale because it has been open for 28 days with no activity.

[github-actions]

This issue is stale because it has been open for 28 days with no activity.