Feature request: External Caching

[grizzlybearer]

Motivation

We leverage OpenFGA server side in-memory caching of sub-problems of the Check API that improves latency and throughput (due to the reduction of DB calls). However, we’re unable to fully utilize the cache due to few factors:

• First-time caching does not reduce latencies of those requests and their P90-99 may be high
• Caching is in-memory server-side and we have multiple server instances. Hence requests may not always hit the server instance where the sub-problem was previously cached.

Goal

Goal 1: Support external data stores for OpenFGA Check Caching
This would improve the cache hit percentage of an OpenFGA multi-instance setup since cache results are stored in an external store and not in-memory

• re-used across multi instances
• persist on a service restart

Goal 2: Support OpenFGA ListObjects Caching
ListObjects API is used in 1 of our critical user paths (search pre-filtering with permissions).
The same data (user to groups) is used for a user and a ripe candidate for caching.
This has multiple benefits:

• improves the latency of ListObjects API
• reduces the number of DB IO calls and indirectly improve the latency of Check API

Solution Overview

OpenFGA would use a server-side L1 L2 caching strategy where:

• L1 continues to be the in-memory cache
• L2 is a configurable external data store (for instance Redis)

[Vic-Dev]

We have a roadmap item for this openfga/roadmap#21.

[grizzlybearer]

thanks for pointing me to it.