[ENG-740] 1/6: Redis cache manager

[johnewart]

Ticket ENG-2757

Description Of Changes

TL;DR - redis cache manager with automatic set-based key indexing, lazy migration of old keys, is not used in any APIs or async functions in this PR, it is purely the storage logic.

This PR lays the groundwork for a Redis cache layer that avoids using KEYS (and eventually SCAN) by providing a convenience layer for secondary index storage (and also as a starting point for other Redis improvements like clustering, enhanced logging, monitoring, etc). This implementation provides the following (and nothing else) - a RedisCacheManager that provides a layer around the Redis client to automatically handle secondary indexing of keys so that they can be cleared and queried without synchronous (and slow) access like KEYS (or SCAN). It does this by allowing you to specify an index name and then transparently recording keys that are related to that index in a Redis set with that name (i.e dsr:1234 or something). Then you can quickly get all the keys for iteration or determine membership, etc.

The RedisCacheManager is not used in any active API/async worker code in this PR, it is purely a base for the follow ons - DSR storage layer, identity cache, encryption and custom fields, request body, etc. in subsequent PRs.

Code Changes

• Initial RedisCacheManager with secondary indexing

Steps to Confirm

1. No manual steps

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ready	Preview, Comment	Feb 24, 2026 10:38pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
fides-privacy-center	Ignored		Feb 24, 2026 10:38pm

[greptile-apps]

Greptile Summary

This PR introduces a foundational RedisCacheManager that provides set-based key indexing to avoid expensive KEYS and SCAN operations in Redis. The implementation is clean, well-documented, and includes comprehensive test coverage.

Key Features:

• Set-based secondary indexing using Redis sets (stored with __idx: prefix)
• Pipeline-based atomic operations for setting/deleting keys with index updates
• Optional TTL management for index sets (opt-in via index_ttl_enabled parameter)
• Consistent string return types from get_keys_by_index (handles bytes conversion)

Test Coverage:

• All public methods have dedicated tests including edge cases
• MockRedis implementation provides realistic testing without external dependencies
• TTL functionality comprehensively tested with multiple scenarios

The implementation properly addresses previous review feedback regarding bytes/string handling and index TTL management. No active API or async worker code uses this manager yet - it's purely foundational infrastructure for follow-on PRs.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• Clean implementation of foundational infrastructure with excellent test coverage. The RedisCacheManager provides a well-designed abstraction for Redis key indexing with proper pipeline usage, comprehensive edge case handling, and thorough documentation. Previous review feedback has been properly addressed. Since this is not yet used in active code paths, there is no risk of production impact.
• No files require special attention

Important Files Changed

Filename	Overview
src/fides/common/cache/manager.py	New RedisCacheManager implementation with set-based indexing and optional TTL management. Clean implementation with good documentation.
tests/common/cache/test_manager.py	Comprehensive test coverage with MockRedis implementation. Tests cover all public methods, edge cases, and TTL functionality.

_{Last reviewed commit: b1a43cc}

[greptile-apps]

_{5 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[JadeCara]

Looks solid! I left a few smaller comments etc but approving so you can merge when ready :)

The only main question I have is - I see all the mechanics we need to handle the indexes well. If keys get expired via TTL the index set doesn't get automatically evicted. In implementation we should be more explicit about it, but it might be worth adding a prune function to clean up any any index members whose data keys no longer exist.

[greptile-apps]

_{8 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}