Stale Cache After Policy Update in Ory Keto: Unresolved Invalidation Strategy

Goal

Determine how Ory Keto handles cache invalidation when policy changes occur, ensuring no stale decisions persist beyond the configured TTL.

Constraints & Uncertainty

• In‑memory cache keyed by CACHE_TTL_SECONDS, default 300 s.
• Documentation does not specify automatic invalidation triggers on policy mutation.
• Concurrent evaluations may read stale entries until TTL expiry.
• The /flush endpoint exists, but its effect on in‑flight requests and across replicas is undocumented.
• Horizontal scaling introduces separate in‑memory stores per pod, raising consistency questions.

Open Questions

What mechanisms does Keto use to detect policy changes and invalidate affected cache entries?

Does the /flush endpoint guarantee immediate consistency across all replicas, or is there a window of stale responses?

Which strategy—write‑through cache, invalidation queue, or TTL‑only—provides the most reliable consistency for high‑traffic environments?