Cache Management for Enforcement & Querying

[mariajgrimaldi]

Description

For the MVP, cache management should remain minimal. The focus is ensuring correctness and predictable behavior of authorization checks, not performance optimization. The solution may even be to disable caching altogether, as long as the system remains reliable.

Problem

• Stale data: Any cache introduces a risk of serving outdated policy data if not refreshed correctly.
• Complexity: A full-featured caching strategy would increase implementation and operational complexity, which is not in scope for the MVP.
• Lifecycle dependency: Cache behavior must stay aligned with the enforcer’s load/clear lifecycle to avoid inconsistencies.

Requirements

1. Define a clear stance for cache management in the MVP:
   • Minimal or disabled caching is acceptable.
   • Any cache usage must not compromise correctness.
2. Ensure that cache handling does not interfere with the policy lifecycle management.
3. Document the chosen approach and make sure it can evolve in later iterations.

Acceptance Criteria

• The MVP includes a defined approach for cache management, even if the approach is simply “no cache.”
• The system continues to provide correct enforcement results under the chosen approach.
• Tests confirm that the cache (if present) does not cause stale or inconsistent reads.

Notes

• This issue is connected to Policy Lifecycle Load and Clear Management since cache handling directly impacts freshness guarantees.
• Performance optimizations can be explored in future iterations once lifecycle correctness is fully established.

[mariajgrimaldi]

https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5210112002/Open+edX+AuthZ+Framework+Long-Term+Vision#Policy-Loading-Strategy

[mariajgrimaldi]

I initially opened this issue to support the Open edX AuthZ Framework Long-Term Vision (see https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5210112002/Open+edX+AuthZ+Framework+Long-Term+Vision#Policy-Loading-Strategy), which was meant to guide the framework in the long term. Now that we understand better the technology we chose and how it integrates with the Open edX ecosystem, it is a good moment to revisit some of the hypotheses from the first design.

One of those hypotheses was the need for a cache strategy. At this point, it seems we may not need a defined caching strategy yet. Implementing one now could cost more effort than the benefits it brings.

During the initial implementation of the framework, we did encounter a performance issue. We solved it by adding caching in response to that specific problem: e8d27f6. Following this reactive approach may make sense for now while we continue learning about the framework’s impact on the platform.

I'll be closing this issue as not planned, we can re-open it later if needed.

[mariajgrimaldi]

FYI @rodmgwgu @bmtcril