Right now the Redis directory implementation is design to take the whole redis instance. The scope of this task is to change such that to take just a logical database.

Why would want to use multiuple logical databases? It is not an unambiguously better way to use Redis.

From AI:

Redis Logical Database¶

A Redis logical database is a separate, isolated namespace within a single running Redis instance. It acts as a distinct internal compartment, allowing you to use identical keys across different logical databases without any name conflicts.

Key Characteristics¶

• Default Count: A standard Redis Open Source instance provides 16 logical databases by default.
• Index-Based: They do not have custom text names. They are identified by numbers ranging from 0 to 15.
• Initial Connection: Your application automatically connects to database 0 by default.
• Navigation: You can switch between these databases by executing the SELECT command (e.g., SELECT 1).

Core Benefits¶

• Namespace Isolation: You can isolate data environments (like staging and testing) without deploying entirely new server hardware.
• Targeted Operations: You can wipe a single logical database using FLUSHDB without erasing data stored in the other 15 compartments.

Production Risks and Limitations¶

Despite the convenience of internal separation, using multiple logical databases is widely considered a production anti-pattern for several reasons:

• Single-Threaded Shared Fate: Redis is primarily single-threaded. If database 2 runs a slow, heavy operation, it will block database 0 and all other databases completely.
• Shared Configurations: All 16 databases must share the exact same configuration rules. You cannot apply a different maximum memory limit or eviction policy (like LRU) to individual logical databases.
• No Cluster Support: If your application expands to require a Redis Cluster, you cannot use multiple logical databases. Redis Cluster only supports database 0.
• No Security Separation: A client with access to the instance can switch between any of the numbered databases freely, making it insecure for separating multi-tenant apps.

Recommended Alternatives¶

If you need to segment your data safely, modern infrastructure practices recommend avoiding logical databases in favor of these options:

• Key Prefixes: Differentiate keys within database 0 using a string separator (e.g., app1:user:100 vs app2:user:100).
• Separate Instances: Run independent physical Redis processes via Docker or managed services. This ensures true resource isolation, independent scaling, and distinct security policies.

Lets say in customer setup, it will have the directory data on database numbered 0, other process required by customer that does require Redis will use database 1, 2 and so on. It just seems a better resources management approach then use of a redis instance just for directory.

The directory is the source of all truth in FWD configuration. Additionally, its performance is also quite important to FWD. The redis instance should be dedicated to FWD use and it must be highly secured.

I would move away from this logical database approach.