Add access decision caching with safe invalidation

[Lakes41]

Difficulty: Advanced

Type: Feature

Summary

Add optional caching for access decisions to reduce repeated policy evaluation and database reads while keeping invalidation safe when memberships, roles, policies, or resources change.

Current Behaviour

Each access check evaluates current database state and policy logic directly. This is correct but can become expensive under high traffic.

Expected Behaviour

The API should support an optional cache for access decisions with clear keys, TTLs, and invalidation on access-affecting changes.

Suggested Implementation

Introduce a cache service interface backed by Redis when configured and disabled by default otherwise. Key decisions by community, wallet, resource, and relevant policy version. Invalidate on membership, role, resource, and policy mutations.

Files or Areas Likely Affected

• apps/access-api/src/services/memberService.ts
• apps/access-api/src/services/cacheService.ts
• apps/access-api/src/config.ts
• apps/access-api/prisma/schema.prisma
• .env.example

Acceptance Criteria

• Access decision cache can be enabled or disabled through config
• Cache keys include wallet, community, and resource identifiers
• Cache entries have bounded TTLs
• Membership and role changes invalidate affected entries
• Policy and resource changes invalidate affected entries
• Tests cover cache hit, miss, TTL expiry, and invalidation behaviour

Additional Notes

Do not cache sensitive secrets. Cache only safe decision metadata and reason codes.

[MoscowDev]

I’d like to take this issue on. I have experience implementing safe caching layers around authorization systems, and I understand the importance of balancing performance gains with strict invalidation guarantees in access-control flows.

My approach would be to introduce an optional, Redis-backed caching layer that is fully disabled by default and only stores non-sensitive access decision metadata.

Specifically, I would:

• Introduce a CacheService abstraction in apps/access-api/src/services/cacheService.ts with:

  • A no-op in-memory implementation (default)
  • A Redis-backed implementation when enabled via config

• Add configuration toggles in apps/access-api/src/config.ts to enable/disable caching cleanly without code changes

• Define deterministic cache keys based on:

  • wallet
  • community
  • resource
  • policy version (to avoid stale policy evaluations)

For correctness and safety:

• Cache only access decision results (e.g. allow/deny + reason code), never secrets or raw policy data

• Enforce bounded TTLs on all cached entries

• Ensure cache is invalidated on:

  • Membership changes
  • Role updates
  • Policy updates
  • Resource modifications

I would integrate invalidation hooks into memberService.ts and other mutation paths so that any access-affecting change clears relevant cached decisions immediately.

Additionally, I would:

• Add Prisma schema considerations if any cache-related metadata needs persistence or audit tracking

• Update .env.example to include Redis/cache configuration flags

• Add comprehensive tests covering:

  • Cache hit behavior
  • Cache miss fallback to DB evaluation
  • TTL expiry behavior
  • Invalidation on membership/role/policy/resource updates

This will improve performance under load while preserving strict correctness guarantees in access control decisions.

[Glam26]

I'd like to take this issue on.

I've built caching layers for authorization systems, policy engines, and high-traffic APIs where correctness is just as important as performance. My experience includes Redis-backed cache abstractions, cache-key design, TTL strategies, event-driven invalidation, and ensuring permission changes are reflected immediately without introducing stale-access risks.

For this implementation, I'll keep caching opt-in and backward compatible, design cache keys around wallet/community/resource context and policy versions, and ensure invalidation is triggered by all access-affecting mutations such as membership, role, policy, and resource updates. I'll also add comprehensive test coverage for cache hits, misses, expiration, and invalidation scenarios to verify both performance gains and correctness.

[grantfox-oss]

🦊 GrantFox — @MoscowDev has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #56)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.