We employ two main methods for our cache system;

• Data Cache: Using the Multi Version Concurrency Control (MVCC) pattern for Postgres, Permify creates a separate database snapshot for each write and delete operation. This approach enhances performance and ensures a consistent cache. Permify hashes each request and checks for the same key in the cache. If not found, it runs the check engine and writes the result to the cache. This also allows for historical data storage, albeit with the downside of accumulating many relationships. To tackle this, Permify has developed a garbage collector to delete old data at specified intervals.
• Distributed Cache: Permify employs Consistent Hashing across its distributed instances to allow for a distributed cache across availability zones. This method hashes the request and identifies the appropriate node/instance that will store the request’s data. This approach ensures high availability, resilience to node or zone failures, and improved performance due to data locality benefits. Consistent Hashing operates independently of the number of objects in the distributed hash table, effectively creating a natural load balancer across cache nodes.

OpenFGA Cache Method

FGA has a cache that is set to 10 seconds. If we decide that a very small set of users is going to be active, we’d be able to serve all the requests from the cache. That would make it very easy to misrepresent the test results, as serving everything from memory would only happen in very specific use cases and won’t take into consideration the execution paths that require database access.

source: https://auth0.com/blog/getting-unlimited-scalability-with-okta-fine-grained-authorization/

Concerns and Opinions on OpenFGA's 10-Second Cache Duration

Security Issues:

Potential for Inaccurate Decisions: The 10-second cache duration may lead to outdated or incomplete data being used for authorization decisions. Because the cache is refreshed so frequently, it may not always capture the most current state of user permissions or data changes, potentially resulting in incorrect or inconsistent access control outcomes.

Cache Hit Rate Issues:

Limited Cache Effectiveness: With such a short cache duration, the cache might not be hit frequently, especially if user activity is low. This results in many requests being served directly from the database rather than the cache. As a result, the performance benefits of caching are diminished, and database load remains high. This setup can also lead to misleading performance metrics, as the cache may only be effective in very specific scenarios and not under typical operational conditions.